public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Williams <pwil3058@bigpond.net.au>
To: MAEDA Naoaki <maeda.naoaki@jp.fujitsu.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	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>, 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>
Subject: Re: [ckrm-tech] [RFC 0/4] sched: Add CPU rate caps (improved)
Date: Wed, 07 Jun 2006 22:44:45 +1000	[thread overview]
Message-ID: <4486CA3D.6000400@bigpond.net.au> (raw)
In-Reply-To: <448688B2.2030206@jp.fujitsu.com>

MAEDA Naoaki wrote:
> Peter Williams wrote:
> 
>> 4. Overhead Measurements.  To measure the implications for overhead
>> introduced by these patches kernbench was used on a dual 500Mhz
>> Centrino SMP system.  Runs were done for a kernel without these
>> patches applied, one with the patches applied but no caps being used
>> and one with the patches applied and running kernbench with a soft cap
>> of zero (which would be inherited by all its children).
>>
>> Average Optimal -j 8 Load Run:
>>
>>                   Vanilla          Patch Applied    Soft Cap 0%
>>
>> Elapsed Time      1056.1   (1.92)  1048.2   (0.62)  1064.1   (1.59)
>> User Time         1908.1   (1.09)  1895.2   (1.30)  1926.6   (1.39)
>> System Time        181.7   (0.60)   177.5   (0.74)   173.8   (1.07)
>> Percent CPU        197.6   (0.55)   197.0   (0)      197.0   (0)
>> Context Switches 49253.6 (136.31) 48881.4  (92.03) 92490.8 (163.71)
>> Sleeps           28038.8 (228.11) 28136.0 (250.65) 25769.4 (280.40)
> 
> I tried to run kernbench with hard cap, and then it spent a very
> long time on "Cleaning souce tree..." phase. Because this phase
> is not CPU hog, my expectation is that it act as without cap.
> 
> That can be reproduced by just running "make clean" on top of a
> kernel source tree with hard cap.
> 
> % /usr/bin/time make clean
> 1.62user 0.29system 0:01.90elapsed 101%CPU (0avgtext+0avgdata 
> 0maxresident)k
> 0inputs+0outputs (0major+68539minor)pagefaults 0swaps
> 
>   # Without cap, it returns almost immediately
> 
> % ~/withcap.sh  -C 900 /usr/bin/time make clean
> 1.61user 0.29system 1:26.17elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+68537minor)pagefaults 0swaps
> 
>   # With 90% hard cap, it takes about 1.5 minutes.

This is harder capping than I would expect.  I'll look into probable 
causes.  It could be caused by the simplification I made to the 
calculation of sinbin time.

> 
> % ~/withcap.sh  -C 100 /usr/bin/time make clean
> 1.64user 0.34system 3:31.48elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+68538minor)pagefaults 0swaps
> 
>   # It became worse with 10% hard cap.

And so it should.

> 
> % ~/withcap.sh  -c 900 /usr/bin/time make clean
> 1.63user 0.28system 0:01.89elapsed 100%CPU (0avgtext+0avgdata 
> 0maxresident)k
> 0inputs+0outputs (0major+68537minor)pagefaults 0swaps
> 
>   # It doesn't happen with soft cap.

That's because soft caps allow you to go over the cap if no other tasks 
want the CPU.

Thanks for the feedback,
Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

  reply	other threads:[~2006-06-07 12:44 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 [this message]
2006-06-08  7:50   ` Peter Williams
2006-06-09  0:57     ` Peter Williams
2006-06-09  5:50       ` MAEDA Naoaki
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=4486CA3D.6000400@bigpond.net.au \
    --to=pwil3058@bigpond.net.au \
    --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=maeda.naoaki@jp.fujitsu.com \
    --cc=mingo@elte.hu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox