From: "Alex,Shi" <alex.shi@intel.com>
To: Rik van Riel <riel@redhat.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"a.p.zijlstra@chello.nl" <a.p.zijlstra@chello.nl>,
"mingo@elte.hu" <mingo@elte.hu>,
"Chen, Tim C" <tim.c.chen@intel.com>,
"Li, Shaohua" <shaohua.li@intel.com>
Subject: Re: [PATCH] sched: recover sched_yield task running time increase
Date: Wed, 06 Apr 2011 14:15:09 +0800 [thread overview]
Message-ID: <1302070509.15889.7351.camel@debian> (raw)
In-Reply-To: <4D9BF512.6080309@redhat.com>
On Wed, 2011-04-06 at 13:07 +0800, Rik van Riel wrote:
> On 04/05/2011 06:33 PM, Alex Shi wrote:
> > commit ac53db596cc08ecb8040c removed the sched_yield task running
> > time increase, so the yielded task get more opportunity to be launch
> > again. That may not the caller want to be. And this also causes
> > volano benchmark drop 50~80 percent performance on core2/NHM/WSM
> > machines. This patch recover the sched_yield task vruntime up.
> >
> > Signed-off-by: alex.shi@intel.com
>
> NACK
>
> This was switched off by default and under
> the sysctl sched_compat_yield for a reason.
>
> Reintroducing it under that sysctl option
> may be acceptable, but by default it would
> be doing the wrong thing for other workloads.
I can implement this as sysctl option. But when I checked again the man
page of sched_yield. I have some concerns on this.
----
int sched_yield(void);
DESCRIPTION
A process can relinquish the processor voluntarily without blocking by calling sched_yield().
The process will then be moved to the end of the queue for its static priority and a new process
gets to run.
----
If a application calls sched_yield system call, most of time it is not
want to be launched again right now. so the man page said "the caller
process will then be moved to the _end_ of the queue..."
next prev parent reply other threads:[~2011-04-06 6:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-05 22:33 [PATCH] sched: recover sched_yield task running time increase Alex Shi
2011-04-06 5:07 ` Rik van Riel
2011-04-06 6:15 ` Alex,Shi [this message]
2011-04-06 7:01 ` Mike Galbraith
2011-04-06 13:28 ` Shi, Alex
2011-04-07 2:44 ` Mike Galbraith
2011-04-06 8:04 ` Peter Zijlstra
2011-04-06 14:42 ` Rik van Riel
2011-04-06 15:25 ` Peter Zijlstra
2011-04-07 3:08 ` Alex,Shi
2011-04-07 6:13 ` Rik van Riel
2011-04-07 6:43 ` Alex,Shi
2011-04-07 8:52 ` Ingo Molnar
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=1302070509.15889.7351.camel@debian \
--to=alex.shi@intel.com \
--cc=a.p.zijlstra@chello.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=riel@redhat.com \
--cc=shaohua.li@intel.com \
--cc=tim.c.chen@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.