[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47C526F8.8010807@linux.vnet.ibm.com>
Date: Wed, 27 Feb 2008 14:31:44 +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, Balbir Singh wrote:
>
>> Let's forget node hotplug for the moment, but what if someone
>>
>> 1. Changes the machine configuration and adds more nodes, do we expect the
>> kernel to be recompiled? Or is it easier to update /etc/sysctl.conf?
>> 2. Uses fake NUMA nodes and increases/decreases the number of nodes across
>> reboots. Should the kernel be recompiled?
>>
>
> That is why the proposal was made to make this a static configuration
> option, such as CONFIG_NUM_RECLAIM_THREADS_PER_NODE, that will handle both
> situations.
>
You mentioned CONFIG_NUM_RECLAIM_THREADS_PER_CPU and not
CONFIG_NUM_RECLAIM_THREADS_PER_NODE. The advantage with syscalls is that even if
we get the thing wrong, the system administrator has an alternative. Please look
through the existing sysctl's and you'll see what I mean. What is wrong with
providing the flexibility that comes with sysctl? We cannot possibly think of
all situations and come up with the right answer for a heuristic. Why not come
up with a default and let everyone use what works for them?
--
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/
Powered by blists - more mailing lists