Rohit Seth wrote: > On Mon, 2005-11-07 at 17:53 -0800, Andrew Morton wrote: > >>"Rohit, Seth" wrote: >> >>>[PATCH]: Clean up of __alloc_pages. Couple of difference from original behavior: >>> 1- remove the initial reclaim logic >>> 2- GFP_HIGH pages are allowed to go little below watermark sooner. >>> 3- Search for free pages unconditionally after direct reclaim. >> >>Would it be possible to break these into three separate patches? The >>cleanup part should be #1. >> > > > Doing the above three things as part of this clean up patch makes the > code look extra clean... Is there any specific issue coming out of 2 & 3 > above. > #2 as I explained I don't like changing this. What this does is basically make __GFP_HIGH allocations sometimes randomly enter direct reclaim rather than have a nice buffer of asynch reclaim like we do now for that and all other types of allocations. It only reduces calls to kswapd by about as much as it will be increasing calls to direct reclaim. Anyway, as promised, I've attached (sorry) a patch to correct the problems I see in it and revert previous behaviour for #2 and #3. I'm not immediately sure of any problems with changing #3, however OOM behaviour is pretty fragile and I wouldn't like to change it as part of this patch. > >>>+ if (!skip_cpuset_chk && (!cpuset_zone_allowed(z, gfp_mask))) >> >>It'd be nice to not have the `skip_cpuset_chk' flag there. a) it gives >>Linus conniptions and b) it's a little extra overhead for !CONFIG_CPUSETS >>kernels. >> > The compiler will constant fold this out if it is halfway smart. > > I think it will be easier to do this change as a follow on patch as that > will change the header file, function definition and such. Can we defer > this to separate follow on patch. > > >>>- zone_statistics(zonelist, z); >>>+ zone_statistics(zonelist, page_zone(page)); >> >>Evaluating page_zone() is not completely trivial. Can we avoid the above? > Done. Let me know what you think (compile tested only, at this stage). -- SUSE Labs, Novell Inc.