Messages in this thread | | | Date | Sun, 13 Dec 2009 23:29:45 -0500 | From | Rik van Riel <> | Subject | Re: [PATCH v2] vmscan: limit concurrent reclaimers in shrink_zone |
| |
On 12/13/2009 11:19 PM, Minchan Kim wrote: > On Mon, Dec 14, 2009 at 1:09 PM, Rik van Riel<riel@redhat.com> wrote:
>> A simpler solution may be to use sleep_on_interruptible, and >> simply have the process continue into shrink_zone() if it >> gets a signal. > > I thought it but I was not sure. > Okay. If it is possible, It' more simple. > Could you repost patch with that?
Sure, not a problem.
> +The default value is 8. > + > +============================================================= > > > 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. > > > Pessimistically, I assume that the pageout code spends maybe > 10% of its time on locking (we have seen far, far worse than > this with thousands of processes in the pageout code). That > means if we have more than 10 threads in the pageout code, > we could end up spending more time on locking and less doing > real work - slowing everybody down. > > I rounded it down to the closest power of 2 to come up with > an arbitrary number that looked safe :) > === > > We discussed above. > I want to add your desciption into changelog.
The thing is, I don't know if 8 is the best value for the default, which is a reason I made it tunable in the first place.
There are a lot of assumptions in my reasoning, and they may be wrong. I suspect that documenting something wrong is probably worse than letting people wonder out the default (and maybe finding a better one).
-- All rights reversed.
| |