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
next prev parent 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