All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>, Mike Galbraith <efault@gmx.de>,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	Paul Turner <pjt@google.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] sched: steer waking task to empty cfs_rq for better latencies
Date: Tue, 24 Apr 2012 22:56:03 +0530	[thread overview]
Message-ID: <20120424172603.GB28701@linux.vnet.ibm.com> (raw)
In-Reply-To: <1335287354.28150.209.camel@twins>

* Peter Zijlstra <peterz@infradead.org> [2012-04-24 19:09:14]:

> On Tue, 2012-04-24 at 18:58 +0200, Peter Zijlstra wrote:
> > On Tue, 2012-04-24 at 22:26 +0530, Srivatsa Vaddagiri wrote:
> > > Steer a waking task towards a cpu where its cgroup has zero tasks (in
> > > order to provide it better sleeper credits and hence reduce its wakeup
> > > latency). 
> > 
> > That's just vile.. pjt could you post your global vruntime stuff so
> > vatsa can have a go at that?
> 
> That is, you're playing a deficiency we should fix, not exploit.
> 
> Also, you do a second loop over all those cpus right after we've already
> iterated them..

The first loop doesn't necessarily iterate thr' all cpus (as its looking
for a core that is fully idle - and hence breaks once it finds a busy
sibling).

> furthermore, that 100%+ gain is still way insane, what else is broken?

?

I have tried most benchmarks that were recommended for this kind of
change. Let me know if you suggest any other benchmark ..

> Did you try those paravirt tlb-flush patches and other such weirdness?

I will try that next. But IMHO the benefit of reduced wakeup latencies
should be over and above any benefit we get from paravirtualization.

- vatsa


  reply	other threads:[~2012-04-24 17:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-24 16:56 [PATCH v1] sched: steer waking task to empty cfs_rq for better latencies Srivatsa Vaddagiri
2012-04-24 16:58 ` Peter Zijlstra
2012-04-24 17:07   ` Srivatsa Vaddagiri
2012-04-24 17:12     ` Peter Zijlstra
2012-04-24 17:35       ` Srivatsa Vaddagiri
2012-04-24 18:03         ` Rakib Mullick
2012-04-24 17:09   ` Peter Zijlstra
2012-04-24 17:26     ` Srivatsa Vaddagiri [this message]
2012-05-02 14:01     ` Srivatsa Vaddagiri
2012-05-03  5:43       ` Nikunj A Dadhania

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=20120424172603.GB28701@linux.vnet.ibm.com \
    --to=vatsa@linux.vnet.ibm.com \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=suresh.b.siddha@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 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.