From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6635C04A6A for ; Thu, 3 Aug 2023 13:18:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A585280255; Thu, 3 Aug 2023 09:18:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 355BA28022C; Thu, 3 Aug 2023 09:18:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 21D84280255; Thu, 3 Aug 2023 09:18:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 1016C28022C for ; Thu, 3 Aug 2023 09:18:53 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C773F4118E for ; Thu, 3 Aug 2023 13:18:52 +0000 (UTC) X-FDA: 81082848504.05.B488DBF Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf01.hostedemail.com (Postfix) with ESMTP id C23314000B for ; Thu, 3 Aug 2023 13:18:49 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=none; spf=none (imf01.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp has no SPF policy when checking 202.181.97.72) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691068731; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gl/GZ0rVwJHVsS52BdbNZrCS6aRBGRnTQuRxOvPwXLs=; b=eW1Ffdsd+aF+LYox6OG1iO6qFuYclyppWePwmos7YlHGAxi1EcocH0Gw6T9gXF/VT1jOfQ vFTuJUhR5ncBxBQrOTJ2kRbzBOi3B/D61mAdvdACh+vboHmEOmogMFfw0rG5E0hptvUWrF OQ4Dq9joogvJ2TXo7N0THMsdujyg88I= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; dmarc=none; spf=none (imf01.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp has no SPF policy when checking 202.181.97.72) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691068731; a=rsa-sha256; cv=none; b=s9TnDMr/JZaplj2z9v/5593VBEvHKtQUiwt72sGrlCYkOGiwXfWDPazaSSbvyJ+VwAB3zO IDD/fNQNXwO20M18eYttfMYUsA2Xk2g35tmaH/K/PhcRwFz/03h2CPkuffp4BHa6nEQ4UC 2YIOoszh/ZLj1+pc+03TzWXSqithjeQ= Received: from fsav117.sakura.ne.jp (fsav117.sakura.ne.jp [27.133.134.244]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 373DIL50004362; Thu, 3 Aug 2023 22:18:21 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav117.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav117.sakura.ne.jp); Thu, 03 Aug 2023 22:18:21 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav117.sakura.ne.jp) Received: from [192.168.1.6] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 373DIA4l004327 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Aug 2023 22:18:21 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <60d4dc52-9281-9266-4294-b514bd09e6e8@I-love.SAKURA.ne.jp> Date: Thu, 3 Aug 2023 22:18:10 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [PATCH v2 1/2] seqlock: Do the lockdep annotation before locking in do_write_seqcount_begin_nested() To: Michal Hocko , Sebastian Andrzej Siewior Cc: Petr Mladek , linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Luis Claudio R. Goncalves" , Andrew Morton , Boqun Feng , Ingo Molnar , John Ogness , Mel Gorman , Peter Zijlstra , Thomas Gleixner , Waiman Long , Will Deacon References: <20230623171232.892937-1-bigeasy@linutronix.de> <20230623171232.892937-2-bigeasy@linutronix.de> <20230626081254.XmorFrhs@linutronix.de> <20230727151029.e_M9bi8N@linutronix.de> <649fa1a7-4efd-8cc7-92c7-ac7944adc283@I-love.SAKURA.ne.jp> Content-Language: en-US From: Tetsuo Handa In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: C23314000B X-Stat-Signature: mtznyz7y3bb4ezroh5d7o17tkzww7hqh X-Rspam-User: X-HE-Tag: 1691068729-364753 X-HE-Meta: U2FsdGVkX18U7CRkKF5YSI8BwdVzi1pktOwt16ofWxjj2qtfrIW+pS9iT/8RnkFaUTHI61uYLq3lUamJOR1ob41bGWajf2axfjEIsw8HdLwehhaeMFNlZ42DlI7r8r5HRs6pZdqh8OzKEZAMTYocdWzKahir//77zJxKltRpKqHotxqQjkWtWc8hO/d1Y5gqukJizHTkqP+k73ILUWWJymMc7t/tK2nAdwG84JSjoWvL/M5/TR2hAeo4XTrdKYU/3zfztC39E+OgNTLl6f/rV42msBSVsU5p6pYQZW7wFrHpIua6qI8WaydovVYV/7IkCOki6wPwuTTOt43IMi93YsaLut81wx+suyatVkCQuuyjKk4kAXeI9sbNLBua82V5frO+kAKBeyBpU3uQAjg3I1OrWM1mIY5MdAkgJ6ug0QciIzOB5zfRn35IkYdz/rcoVRVR8JfiPIkm7jHICtaC17pMwaZCd2OXuwGNa5TgmBlVqM5NahYX/1HStVlvWmMGWJqSvaWEFkwyNCVuTlNekAtTotq9DFl+foAGEVl9+kckm68Olz8MKDKyFP6VYNgN9FcxjIWr5hK9y9/Y1yqQr5awe2qD8kh0uUK1VFghZqwyoIzw+Op89e8F4npz49i/ZZ8OemjhGj7ClprEMmkCWlgtsCTHwyN7HmZmpMUt77Yb4KPhFQqyk/370Tyf1SR6PZwmF9wFTfOQ52VYGDpfQ9EYPp28EjzZlgpqieUmfHJH5sJJEEdTdl4REWFs1l/NbxQqwLKCqOCOnaqH3Li+Nhh64GLg4sXSTsMMjMEraF5XO2W63aWcPbkPjCPc1x4VrgStyaUTrY9A+UR51wWV4IKT7bJ00M9/t/yEi8RajLe2zAo2MEWLBmY442Jk6QpSlEppSl+++nkYkfmi7m5aL0ajGZt2qAP2aMDZ+ixnyrZ1k271NCtXrBbNgCAfLAVxwuF9H4XAPeKkwCTe888 WmKE53jY +KWPbDqQfJHD36gvFPfZhqJh7+TgG0fuBZXgs8WxWPUItssK1ydpAjz/yuOUBttA/Ck74LOS67cSWyE/MpS7CTgtrm633HHX3kGKDO/FPufRAPZNjjSC9dxrcbTP7kZaqIaivfMgZDuKqGrvttfqovrfW0DxNuXF+qbroZOvVlRw33dJwEJSCAoCKrGRTontsVCK+h7lodHyyqirSCVOSiYkATe1knNfh9IjZNtHclIrkHSCxsSyT1fnd1eSg9sgdMKkBbWq0FdKlkxzvMSmj3nlhs/1FHccfHlmfWJKXcVkxO04Eh1jUAePFrrhCdTrpSCzQzXSSW3wpGdedVJuDONTv9TZrM2pwybWIbMNzBLedPYQXnEICE2bFEgFT3pQoWVjpTi7SE7/vElk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2023/07/31 23:25, Michal Hocko wrote: > On Sat 29-07-23 20:05:43, Tetsuo Handa wrote: >> On 2023/07/29 14:31, Tetsuo Handa wrote: >>> On 2023/07/28 0:10, Sebastian Andrzej Siewior wrote: >>>> On 2023-06-28 21:14:16 [+0900], Tetsuo Handa wrote: >>>>>> Anyway, please do not do this change only because of printk(). >>>>>> IMHO, the current ordering is more logical and the printk() problem >>>>>> should be solved another way. >>>>> >>>>> Then, since [PATCH 1/2] cannot be applied, [PATCH 2/2] is automatically >>>>> rejected. >>>> >>>> My understanding is that this patch gets applied and your objection will >>>> be noted. >>> >>> My preference is that zonelist_update_seq is not checked by !__GFP_DIRECT_RECLAIM >>> allocations, which is a low-hanging fruit towards GFP_LOCKLESS mentioned at >>> https://lkml.kernel.org/r/ZG3+l4qcCWTPtSMD@dhcp22.suse.cz and >>> https://lkml.kernel.org/r/ZJWWpGZMJIADQvRS@dhcp22.suse.cz . >>> >>> Maybe we can defer checking zonelist_update_seq till retry check like below, >>> for this is really an infrequent event. >>> >> >> An updated version with comments added. > > Seriously, don't you see how hairy all this is? And for what? Nitpicking > something that doesn't seem to be a real problem in the first place? Seriously, can't you find "zonelist_update_seq is not checked by !__GFP_DIRECT_RECLAIM allocations, which is a low-hanging fruit towards GFP_LOCKLESS" !? My initial proposal was "[PATCH] mm/page_alloc: don't check zonelist_update_seq from atomic allocations" at https://lkml.kernel.org/r/dfdb9da6-ca8f-7a81-bfdd-d74b4c401f11@I-love.SAKURA.ne.jp . Compared to that version, this what-you-call-hairy version has an improvement that - return read_seqbegin(&zonelist_update_seq); + return data_race(READ_ONCE(zonelist_update_seq)); can eliminate while ((__seq = seqprop_sequence(s)) & 1) cpu_relax(); path. There is no need to wait for completion of rebuilding zonelists, for rebuilding zonelists being in flight (indicated by zonelist_update_seq being odd) does not mean that allocation never succeeds. When allocation did not fail, this "while" loop becomes nothing but a waste of CPU time, And it is very likely that rebuilding zonelists being not in flight from the beginning. We can make zonelist_iter_begin() (which is always called as long as __alloc_pages_slowpath() is called) faster and simpler, which is an improvement even without considering printk() and lockdep/KCSAN related problems.