Messages in this thread | | | Date | Fri, 11 Dec 2009 23:08:42 +0900 | Subject | Re: [PATCH] vmscan: limit concurrent reclaimers in shrink_zone | From | Minchan Kim <> |
| |
On Fri, Dec 11, 2009 at 10:51 PM, Rik van Riel <riel@redhat.com> wrote: > On 12/11/2009 08:41 AM, Minchan Kim wrote: >> >> Hi, Larry. >> >> On Fri, Dec 11, 2009 at 9:07 PM, Larry Woodman<lwoodman@redhat.com> >> wrote: >>> >>> Minchan Kim wrote: >>>> >>>> I like this. but why do you select default value as constant 8? >>>> Do you have any reason? >>>> >>>> I think it would be better to select the number proportional to NR_CPU. >>>> ex) NR_CPU * 2 or something. >>>> >>>> Otherwise looks good to me. >>>> >>>> Reviewed-by: Minchan Kim<minchan.kim@gmail.com> >>>> >>>> >>> >>> This is a per-zone count so perhaps a reasonable default is the number of >>> CPUs on the >>> NUMA node that the zone resides on ? >> >> For example, It assume one CPU per node. >> It means your default value is 1. >> On the CPU, process A try to reclaim HIGH zone. >> Process B want to reclaim NORMAL zone. >> But Process B can't enter reclaim path sincev throttle default value is 1 >> Even kswap can't reclaim. > > 1) the value is per zone, so process B can go ahead
Sorry. I misunderstood Larry's point. I though Larry mentioned global limit not per zone.
> 2) kswapd is always excempt from this limit, since > there is only 1 kswapd per node anyway
Larry could test with Rik's patch for what's good default value. If it proves NR_CPU on node is proper as default value, We can change default value with it.
> -- > All rights reversed. >
-- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |