linux-kernel - Re: [RFC][PATCH] page reclaim throttle take2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 Feb 2008 11:18:48 +0530
From:	Balbir Singh <balbir@...ux.vnet.ibm.com>
To:	David Rientjes <rientjes@...gle.com>
CC:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Rik van Riel <riel@...hat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@...com>,
	Nick Piggin <npiggin@...e.de>
Subject: Re: [RFC][PATCH] page reclaim throttle take2

David Rientjes wrote:
> On Wed, 27 Feb 2008, KOSAKI Motohiro wrote:
> 
>>> I disagree, the config option is indeed static but so is the NUMA topology 
>>> of the machine.  It represents the maximum number of page reclaim threads 
>>> that should be allowed for that specific topology; a maximum should not 
>>> need to be redefined with yet another sysctl and should remain independent 
>>> of various workloads.
>> ok.
>>
>>> However, I would recommend adding the word "MAX" to the config option.
>> MAX_PARALLEL_RECLAIM_TASK is good word?
>>
> 
> I'd use _THREAD instead of _TASK, but I'd also wait for Balbir's input 
> because perhaps I missed something in my original analysis that this 
> config option represents only the maximum number of concurrent reclaim 
> threads and other heuristics are used in addition to this that determine 
> the exact number of threads depending on VM strain.
> 


Things are changing, with memory hot-add remove, CPU hotplug , the topology can
change and is no longer static. One can create fake NUMA nodes on the fly using
a boot option as well.

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




-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/