On Thu 03-08-23 22:18:10, Tetsuo Handa wrote: > 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" !? I do not think we have concluded that we want to support GFP_LOCKLESS. This might be trivial straightforward now but it imposes some constrains for future maintainability. So far we haven't heard about many usecases where this would be needed and a single one is not sufficient IMHO. -- Michal Hocko SUSE Labs
