From: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Arun R Bharadwaj <arun@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org,
linux-pm@lists.linux-foundation.org, a.p.zijlstra@chello.nl,
ego@in.ibm.com, tglx@linutronix.de, andi@firstfloor.org,
venkatesh.pallipadi@intel.com, vatsa@linux.vnet.ibm.com,
arjan@infradead.org
Subject: Re: [v2 PATCH 0/4] timers: framework for migration between CPU
Date: Wed, 4 Mar 2009 23:36:57 +0530 [thread overview]
Message-ID: <20090304180657.GA27520@dirshya.in.ibm.com> (raw)
In-Reply-To: <20090304173321.GB25962@elte.hu>
* Ingo Molnar <mingo@elte.hu> [2009-03-04 18:33:21]:
>
> * Arun R Bharadwaj <arun@linux.vnet.ibm.com> wrote:
>
> > $taskset -c 4,5,6,7 make -j4
> >
> > my_driver queuing timers continuously on CPU 10.
> >
> > idle load balancer currently on CPU 15
> >
> >
> > Case1: Without timer migration Case2: With timer migration
> >
> > -------------------- --------------------
> > | Core | LOC Count | | Core | LOC Count |
> > | 4 | 2504 | | 4 | 2503 |
> > | 5 | 2502 | | 5 | 2503 |
> > | 6 | 2502 | | 6 | 2502 |
> > | 7 | 2498 | | 7 | 2500 |
> > | 10 | 2501 | | 10 | 35 |
> > | 15 | 2501 | | 15 | 2501 |
> > -------------------- --------------------
> >
> > --------------------- --------------------
> > | Core | Sleep time | | Core | Sleep time |
> > | 4 | 0.47168 | | 4 | 0.49601 |
> > | 5 | 0.44301 | | 5 | 0.37153 |
> > | 6 | 0.38979 | | 6 | 0.51286 |
> > | 7 | 0.42829 | | 7 | 0.49635 |
> > | 10 | 9.86652 | | 10 | 10.04216 |
> > | 15 | 0.43048 | | 15 | 0.49056 |
> > --------------------- ---------------------
> >
> > Here, all the timers queued by the driver on CPU10 are moved to CPU15,
> > which is the idle load balancer.
>
> The numbers with this automatic method based on the ilb-cpu look
> pretty convincing. Is this what you expected it to be?
Yes Ingo, this is the expected results and looks pretty good. However
there are two parameters controlled in this experiment:
1) The system is moderately loaded with kernbench so that there are
some busy CPUs and some idle cpus, and the no_hz mask is does not
change often. This leads to stable ilb-cpu selection. If the
system is either completely idle or loaded too little leading to
ilb nominations, then timers keep following the ilb cpu and it is
very difficult to experimentally observe the benefits.
Even if the ilb bounces, consolidating timers should increase
overlap between timers and reduce the wakeup from idle.
Optimising the ilb selection should significantly improve
experimental results for this patch.
2) The timer test driver creates quite large timer load so that the
effect of migration is observable as sleep time difference on the
expected target cpu. This kind of timer load may not be uncommon
with lots of application stack loaded in an enterprise system
--Vaidy
next prev parent reply other threads:[~2009-03-04 18:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-04 12:12 [v2 PATCH 0/4] timers: framework for migration between CPU Arun R Bharadwaj
2009-03-04 12:14 ` [v2 PATCH 1/4] timers: framework to identify pinned timers Arun R Bharadwaj
2009-03-05 16:53 ` Oleg Nesterov
2009-03-06 6:14 ` Arun R Bharadwaj
2009-03-06 15:03 ` Oleg Nesterov
2009-03-06 7:01 ` Arun R Bharadwaj
2009-03-04 12:16 ` [v2 PATCH 2/4] timers: identifying the existing pinned hrtimers Arun R Bharadwaj
2009-03-04 12:18 ` [v2 PATCH 3/4] timers: sysfs hook to enable timer migration Arun R Bharadwaj
2009-03-04 12:19 ` [v2 PATCH 4/4] timers: logic " Arun R Bharadwaj
2009-03-04 16:33 ` Daniel Walker
2009-03-04 16:52 ` Arun R Bharadwaj
2009-03-05 15:34 ` Oleg Nesterov
2009-03-05 16:23 ` Oleg Nesterov
2009-03-06 3:21 ` Gautham R Shenoy
2009-03-06 14:50 ` Oleg Nesterov
2009-03-06 15:49 ` Gautham R Shenoy
2009-03-06 17:08 ` Oleg Nesterov
2009-03-06 17:26 ` Gautham R Shenoy
2009-03-04 17:33 ` [v2 PATCH 0/4] timers: framework for migration between CPU Ingo Molnar
2009-03-04 18:06 ` Vaidyanathan Srinivasan [this message]
2009-03-04 18:29 ` Ingo Molnar
2009-03-06 0:14 ` Arjan van de Ven
2009-03-06 4:23 ` Arun R Bharadwaj
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=20090304180657.GA27520@dirshya.in.ibm.com \
--to=svaidy@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=arun@linux.vnet.ibm.com \
--cc=ego@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--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