[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45D406BF.2060009@bull.net>
Date: Thu, 15 Feb 2007 08:07:43 +0100
From: Nadia Derbey <Nadia.Derbey@...l.net>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 6/6] automatic tuning applied to some kernel components
Eric W. Biederman wrote:
> Nadia Derbey <Nadia.Derbey@...l.net> writes:
>
>
>>So, should I understand from this that automatic tuning and the AKT framework
>>itself would make sense, given that I find the rigth tunables it should be
>>applied to?
>
>
> Sort of. The concept of things tuning themselves automatically makes
> a lot of sense.
>
> I'm not at all certain about tunables being exported just to be hidden
> again. Ideally you don't even want the fact that these things are
> varying visible to the user.
>
> So I think that if you can find a good example that cannot be solved
> better another way, you can build a case for your framework.
> Currently I am doubt you can find such a case.
>
>
>>Actually, dont' know if you had the opportunity to read all the patches, but
>>there are 2 other tunables AKT is proposed to be applied to:
>>. max_threads, the tunable limit on nr_threads
>>. max_files, the tunable limit on nr_files
>
>
> At a quick glance max_threads and max_files appear even more to be
> DOS limits and not tunables and even less applicable to needing any
> tuning at all. My gut feel is at worst these values may need a little
> better boot time defaults but otherwise they the should be good.
>
But, what do you do with Oracle that's asking maxfiles to be set to
0x10000, while the default value might be enough for a system that's not
running Oracle.
I'm afraid that giving boot time values to the max_* tunables we will
loose all the benefits from /proc (or /sys): it is impossible to
anticipate what an OS will be used for. So allowing such things to be
changed without having to reboot the machine is in my mind quite a
powerful feature we should keep taking adavntage of.
Regards,
Nadia
-
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