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@xxxxxxxxxxxxxx and >>> https://lkml.kernel.org/r/ZJWWpGZMJIADQvRS@xxxxxxxxxxxxxx . >>> >>> 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@xxxxxxxxxxxxxxxxxxx . 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.
