From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Cc: mingo@elte.hu, pjt@google.com, efault@gmx.de, venki@google.com,
suresh.b.siddha@intel.com, linux-kernel@vger.kernel.org,
"Nikunj A. Dadhania" <nikunj@linux.vnet.ibm.com>
Subject: Re: sched: Performance of Trade workload running inside VM
Date: Mon, 20 Feb 2012 15:56:30 +0100 [thread overview]
Message-ID: <1329749790.2293.354.camel@twins> (raw)
In-Reply-To: <20120218074127.GA9077@linux.vnet.ibm.com>
On Sat, 2012-02-18 at 13:11 +0530, Srivatsa Vaddagiri wrote:
> * Peter Zijlstra <a.p.zijlstra@chello.nl> [2012-02-15 18:45:02]:
> > why does your patch sort it etc.
>
> The patch does result in a hunt for "least" busy cpu when the target cpu
> returned by select_idle_sibling() is not idle - thus resulting in better
> scheduling latencies for the task (and in turn better benchmark scores).
>
> Another variant of the patch could be to have select_idle_sibling() look
> for any idle cpu that is in same cache domain (rather than looking for a
> whole group of cpus to be idle)?
Right, so I looked over select_idle_sibling() again and it made my head
hurt :/ I can't immediately tell if its actually doing the right thing
or not (it _should_ try and avoid using SMT siblings if possible).
It would be very nice not to have both select_idle_sibling() and
SD_BALANCE_WAKE iterate the domain tree. So merging them if at all
possible would be goodness I think.
We'd have WAKE_AFFINE to decide which cache domain etc to stuff the task
on and then use select_idle_sibling() to find the most appropriate cpu
within that cache domain.
There was talk of modifying select_idle_sibling() to also consider the
C-state the cpu was in, preferring shallower over deeper C-states where
there's choice, this is very similar to what you propose, taking the
least loaded cpu when there isn't a proper idle one around.
next prev parent reply other threads:[~2012-02-20 14:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-14 11:28 sched: Performance of Trade workload running inside VM Srivatsa Vaddagiri
2012-02-15 11:59 ` Peter Zijlstra
2012-02-15 17:10 ` Srivatsa Vaddagiri
2012-02-15 17:24 ` Peter Zijlstra
2012-02-15 17:38 ` Srivatsa Vaddagiri
2012-02-15 17:45 ` Peter Zijlstra
2012-02-15 17:56 ` Srivatsa Vaddagiri
2012-02-18 7:41 ` Srivatsa Vaddagiri
2012-02-20 14:56 ` Peter Zijlstra [this message]
2012-02-20 15:09 ` Srivatsa Vaddagiri
2012-02-15 17:26 ` Peter Zijlstra
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=1329749790.2293.354.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nikunj@linux.vnet.ibm.com \
--cc=pjt@google.com \
--cc=suresh.b.siddha@intel.com \
--cc=vatsa@linux.vnet.ibm.com \
--cc=venki@google.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.