[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4863AF57.3040005@linux.vnet.ibm.com>
Date: Thu, 26 Jun 2008 20:31:43 +0530
From: Balbir Singh <balbir@...ux.vnet.ibm.com>
To: Andi Kleen <andi@...stfloor.org>
CC: Linux Kernel <linux-kernel@...r.kernel.org>,
svaidy@...ux.vnet.ibm.com,
Suresh B Siddha <suresh.b.siddha@...el.com>,
Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Dipankar Sarma <dipankar@...ibm.com>,
Vatsa <vatsa@...ux.vnet.ibm.com>,
Gautham R Shenoy <ego@...ibm.com>
Subject: Re: [RFC v1] Tunable sched_mc_power_savings=n
Andi Kleen wrote:
> Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com> writes:
>> The idea being proposed is to enhance the tunable with varied degrees
>> of consolidation that can work best for different workload
>> characteristics. echo 2 > /sys/.../sched_mc_power_savings could
>> enable more aggressive consolidation than the default.
>
> It would be better to fix the single power saving default to work
> better with bursty workloads too than to add more tunables. Tunables
> are basically "we give up, let's push the problem to the user"
> which is not nice. I suspect a lot of users won't even know if their
> workloads are bursty or not. Or they might have workloads which
> are both bursty and not bursty.
>
> Or did you try that and failed?
>
A user could be an application and certain applications can predict their
workload. For example, a database, a file indexer, etc can predict their workload.
Policies are best known in user land and the best controlled from there.
Consider a case where the end user might select a performance based policy or a
policy to aggressively save power (during peak tariff times). With
virtualization, the whole concept of application is changing, the OS by itself
could be an application :)
--
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