mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dipankar Sarma <dipankar@in.ibm.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	svaidy@linux.vnet.ibm.com,
	Suresh B Siddha <suresh.b.siddha@intel.com>,
	Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>,
	Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	Vatsa <vatsa@linux.vnet.ibm.com>,
	Gautham R Shenoy <ego@in.ibm.com>
Subject: Re: [RFC v1] Tunable sched_mc_power_savings=n
Date: Thu, 26 Jun 2008 20:31:00 +0530	[thread overview]
Message-ID: <20080626150100.GA26167@in.ibm.com> (raw)
In-Reply-To: <87k5gcqpbm.fsf@basil.nowhere.org>

On Thu, Jun 26, 2008 at 03:49:01PM +0200, Andi Kleen wrote:
> Vaidyanathan Srinivasan <svaidy@linux.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?

I think we have a reasonable default with sched_mc_power_savings=1.
Beyond that it hard to figure out how much work you can group together
and run in a small number of physical CPU packages. The approach
we are taking is to let system administrators decide what level
of power savings they want. If they want power savings at the cost
of performance, they should be able to do so using a higher
value of sched_mc_power_savings. If they see that they can pack
more work without affecting their transaction time, they should
be able to adjust the level of packing. Beyond a sane default,
it is hard to do this inside the kernel.

Thanks
Dipankar

  reply	other threads:[~2008-06-26 15:04 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-25 19:11 Vaidyanathan Srinivasan
2008-06-26 13:49 ` Andi Kleen
2008-06-26 15:01   ` Dipankar Sarma [this message]
2008-06-26 18:31     ` Vaidyanathan Srinivasan
2008-06-26 15:01   ` Balbir Singh
2008-06-26 18:08     ` Andi Kleen
2008-06-26 18:52       ` Vaidyanathan Srinivasan
2008-06-26 19:37         ` David Collier-Brown
2008-06-27  6:50           ` Vaidyanathan Srinivasan
2008-06-26 20:17         ` Andi Kleen
2008-06-26 21:00           ` Dipankar Sarma
2008-06-26 21:37             ` Andi Kleen
2008-06-26 21:43               ` Peter Zijlstra
2008-06-26 22:38                 ` Andi Kleen
2008-06-27  6:24                   ` Vaidyanathan Srinivasan
2008-06-27  7:51                   ` Peter Zijlstra
2008-06-27  8:06                     ` Andi Kleen
2008-06-28 11:35                       ` Tim Connors
2008-06-28 11:55                         ` Andi Kleen
2008-06-28 12:22                       ` Matthew Garrett
2008-06-28 12:36                         ` Andi Kleen
2008-06-28 12:53                           ` Matthew Garrett
2008-06-28 11:22                   ` Tim Connors
2008-06-29 18:02                     ` David Collier-Brown
2008-06-30  4:57                       ` Vaidyanathan Srinivasan
2008-06-30  5:55                         ` Tim Connors
2008-06-30 14:18                         ` David Collier-Brown
2008-06-30 14:31                           ` Andi Kleen
2008-06-27  4:54               ` Dipankar Sarma
2008-06-27  8:03                 ` Andi Kleen
2008-06-30 16:10                   ` Dipankar Sarma
2008-06-27  7:19           ` Vaidyanathan Srinivasan
2008-06-27  4:15       ` Balbir Singh
2008-06-27  8:08 ` KOSAKI Motohiro
2008-06-27  8:50   ` Vaidyanathan Srinivasan
2008-06-27 12:54   ` David Collier-Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080626150100.GA26167@in.ibm.com \
    --to=dipankar@in.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=andi@firstfloor.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=ego@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=suresh.b.siddha@intel.com \
    --cc=svaidy@linux.vnet.ibm.com \
    --cc=vatsa@linux.vnet.ibm.com \
    --cc=venkatesh.pallipadi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome