All of lore.kernel.org
 help / color / mirror / Atom feed
From: MAEDA Naoaki <maeda.naoaki@jp.fujitsu.com>
To: Peter Williams <peterw@aurema.com>
Cc: Peter Williams <pwil3058@bigpond.net.au>,
	Kirill Korotaev <dev@openvz.org>, Srivatsa <vatsa@in.ibm.com>,
	CKRM <ckrm-tech@lists.sourceforge.net>,
	Balbir Singh <bsingharora@gmail.com>,
	Mike Galbraith <efault@gmx.de>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Con Kolivas <kernel@kolivas.org>, Sam Vilain <sam@vilain.net>,
	Kingsley Cheung <kingsley@aurema.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Ingo Molnar <mingo@elte.hu>,
	Rene Herman <rene.herman@keyaccess.nl>,
	MAEDA Naoaki <maeda.naoaki@jp.fujitsu.com>
Subject: Re: [ckrm-tech] [RFC 0/4] sched: Add CPU rate caps (improved)
Date: Fri, 09 Jun 2006 14:50:02 +0900	[thread overview]
Message-ID: <44890C0A.1000005@jp.fujitsu.com> (raw)
In-Reply-To: <4488C765.2050108@aurema.com>

Peter Williams wrote:
> 
> I've done some informal testing with smaller values of CAP_STATS_OFFSET 
> and there is only a minor improvement.
> 
> However, something that does improve behaviour for short lived tasks is 
> to increase the value of HZ.  This is because the basic unit of CPU
> allocation by the scheduler is 1/HZ and this is also the minimum time 
> (and granularity) with which sinbinning and other capping measures can 
> be implemented.  This is the fundamental limiting factor for the 
> accuracy of capping i.e. if everything worked perfectly the best 
> granularity that can be expected from capping of short lived tasks is 
> 1000 / (HZ * duration) where duration is in seconds.

I already defines CONFIG_HZ=1000. Do you suggest increasing more?

> For longer living tasks, once the initial phase has passed the half life 
> of the Kalman filters takes over from "HZ * duration" in the above 
> expression.  Reducing CAP_STATS_OFFSET will shorten the half life of the 
> filters and this in turn will make capping coarser.  On the other hand, 
> if the half lives are too big then capping will be too slow in reacting 
> to changes in a task's CPU usage patterns.  So there's a sweet spot in 
> there somewhere.  There's also an upper limit imposed by the likelihood 
> of arithmetic overflow during the calculations and this has to consider 
> the fact that the average cycle length (one of the metrics) can be quite 
> long.  The current values was based on these considerations.
> 
> Peter

Thanks,
MAEDA Naoaki


  reply	other threads:[~2006-06-09  5:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060606023708.2801.24804.sendpatchset@heathwren.pw.nest>
2006-06-07  8:05 ` [ckrm-tech] [RFC 0/4] sched: Add CPU rate caps (improved) MAEDA Naoaki
2006-06-07 12:44   ` Peter Williams
2006-06-08  7:50   ` Peter Williams
2006-06-09  0:57     ` Peter Williams
2006-06-09  5:50       ` MAEDA Naoaki [this message]
2006-06-09  6:05         ` Peter Williams
2006-06-09  5:41     ` MAEDA Naoaki
2006-06-09  6:38       ` Peter Williams

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=44890C0A.1000005@jp.fujitsu.com \
    --to=maeda.naoaki@jp.fujitsu.com \
    --cc=bsingharora@gmail.com \
    --cc=ckrm-tech@lists.sourceforge.net \
    --cc=dev@openvz.org \
    --cc=ebiederm@xmission.com \
    --cc=efault@gmx.de \
    --cc=kernel@kolivas.org \
    --cc=kingsley@aurema.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterw@aurema.com \
    --cc=pwil3058@bigpond.net.au \
    --cc=rene.herman@keyaccess.nl \
    --cc=sam@vilain.net \
    --cc=vatsa@in.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.