[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <60d4dc52-9281-9266-4294-b514bd09e6e8@I-love.SAKURA.ne.jp>
Date: Thu, 3 Aug 2023 22:18:10 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Michal Hocko <mhocko@...e.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Petr Mladek <pmladek@...e.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
"Luis Claudio R. Goncalves" <lgoncalv@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Boqun Feng <boqun.feng@...il.com>,
Ingo Molnar <mingo@...hat.com>,
John Ogness <john.ogness@...utronix.de>,
Mel Gorman <mgorman@...hsingularity.net>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Waiman Long <longman@...hat.com>, Will Deacon <will@...nel.org>
Subject: Re: [PATCH v2 1/2] seqlock: Do the lockdep annotation before locking
in do_write_seqcount_begin_nested()
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.
Powered by blists - more mailing lists