![]() | ||||||||||
Messages in this thread |
On Wed, 27 Feb 2008, Balbir Singh wrote: > Since we're talking of parallel reclaims, I think it's a function of CPUs and > Nodes. I'd rather keep it as a sysctl with a good default value based on the > topology. If we end up getting it wrong, the system administrator has a choice. > That is better than expecting him/her to recompile the kernel and boot that. A > sysctl does not create problems either w.r.t changing the number of threads, no > hard to solve race-conditions - it is fairly straight forward > We lack node hotplug, so the dependence on the number of system nodes in the equation is static and can easily be defined at compile-time. I agree that the maximum number of parallel reclaim threads should be a function of cpus, so you can easily make it that by adding callback functions for cpu hotplug events. Perhaps a better alternative than creating a set of heuristics and setting a user-defined maximum on the number of concurrent reclaim threads is to configure the number of threads to be used for each online cpu called CONFIG_NUM_RECLAIM_THREADS_PER_CPU. This solves the lock contention problem if configured properly that was mentioned earlier. Adding yet another sysctl for this functionality seems unnecessary, unless it is attempting to address other VM problems where page reclaim needs to be throttled when it is being stressed. Those issues need to be addressed directly, in my opinion, instead of attempting to workaround it by limiting the number of concurrent reclaim threads. David -- 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/ | |||||||||
| Last update: 2008-02-27 07:15 [from the cache] ©2003-2008 | ||||||||||