Messages in this thread | | | Date | Fri, 11 Dec 2009 22:41:27 +0900 | Subject | Re: [PATCH] vmscan: limit concurrent reclaimers in shrink_zone | From | Minchan Kim <> |
| |
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.
I think it's really agressive throttle approach although it would solve your problem.
I have another idea.
We make default value rather big and we provide latency vaule as knob. So first many processes can enter reclaim path. When shrinking time exceeds our konb(ex, some HZ), we can decrease default value of number of concurrent reclaim process. If shrink time is still long alghouth we do it, we can decrease default vaule again. When shrink time is fast, we can allow to enter reclaim path of another processes as increase the number.
It's like old pdflush mechanism. but it's more complex than Rik's one. If Rik's approach solve this problem well, my approach is rather overkill, I think.
I am looking forward to Rik's approach work well.
> >
-- Kind regards, Minchan Kim
| |