Ack, sorry, I'm wrong.
Please ignore me, if you weren't already.
I'm glad to hear this will be fixed. The task should be moved last for its
priority level.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Chris Friesen wrote:
> > The yielding task has given up the cpu. The other task should get to
> > run for a timeslice (or whatever the equivalent is in CFS) until the
> > yielding task again "becomes head of the thread list".
> Are you sure this isn't happening? I'll run some tests on my SMP
>
> David Schwartz wrote:
> > Nonsense. The task is always ready-to-run. There is no reason
> > its CPU should
> > be low. This bug report is based on a misunderstanding of what yielding
> > means.
> The yielding task has given up the cpu. The other task should get to
> run for a timeslice (or wh
On Wed, 19 Sep 2007 23:41:05 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > Btw, the "enqueue at the end" could easily be a statistical thing, not
> > an absolute thing. So it's possible that we could perhaps implement
> > the CFS "yield()" u
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Peter, what do you think?
>
> Linus, if this would be acceptable for .23 then i'll push it out into
> sched.git together with another fix that Hiroshi Shimamoto just posted
> to lkml.
it's getting late here so i've pushed the current version of those
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Btw, the "enqueue at the end" could easily be a statistical thing, not
> an absolute thing. So it's possible that we could perhaps implement
> the CFS "yield()" using the same logic as we have now, except *not*
> calling the "update_stats()" stuff:
On Wed, 19 Sep 2007, Ingo Molnar wrote:
>
> in CFS we dont have a per-nice-level rbtree, so we cannot move it dead
> last within the same priority group - but we can move it dead last in
> the whole tree. (then they'd be put even after nice +19 tasks.) People
> might complain about _that_.
Y
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> ok, we can do that.
>
> the O(1) implementation of yield() was pretty arbitrary: it did not
> move it last on the same priority level - it only did it within the
> active array. So expired tasks (such as CPU hogs) would come _after_ a
> yield()-ing t
Ingo Molnar wrote:
> The correct way to tell the kernel that the task is blocked is to use
futexes for example, or any kernel-based locking or wait object - there
are myriads of APIs for these. (The only well-defined behavior of yield
is for SCHED_FIFO/RR tasks - and that is fully preserved in
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > Linus, what do you think? I have no strong feelings, I think the
> > patch cannot hurt (it does not change anything by default) - but we
> > should not turn the workaround flag on by default.
>
> I disagree. I think CFS made "sched_yield()" worse
David Schwartz wrote:
Nonsense. The task is always ready-to-run. There is no reason its CPU should
be low. This bug report is based on a misunderstanding of what yielding
means.
The yielding task has given up the cpu. The other task should get to
run for a timeslice (or whatever the equivale
On Wed, 19 Sep 2007, Ingo Molnar wrote:
>
> Linus, what do you think? I have no strong feelings, I think the patch
> cannot hurt (it does not change anything by default) - but we should not
> turn the workaround flag on by default.
I disagree. I think CFS made "sched_yield()" worse, and what
* Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> I just got a bug report today:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=295071
>
> ==
>
> Description of problem:
>
> The CFS scheduler does not seem to implement sched_yield correctly. If
> on
> The CFS scheduler does not seem to implement sched_yield correctly. If one
> program loops with a sched_yield and another program prints out timing
> information in a loop. You will see that if both are taskset to
> the same core
> that the timing stats will be twice as long as when they are on
On 09/18/2007 06:46 PM, Ingo Molnar wrote:
>>> We need a (tested)
>>> solution for 2.6.23 and the CFS-devel patches are not for 2.6.23. I've
>>> attached below the latest version of the -rc6 yield patch - the switch
>>> is not dependent on SCHED_DEBUG anymore but always available.
>>>
>> Is this
* Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> On 09/14/2007 11:32 AM, Ingo Molnar wrote:
> > * Antoine Martin <[EMAIL PROTECTED]> wrote:
> >
> have an impact) Keep CONFIG_SCHED_DEBUG=y to be able to twiddle the
> sysctl.
> >> It looks good now! Updated results here:
> >> http://devloop.o
On 09/14/2007 11:32 AM, Ingo Molnar wrote:
> * Antoine Martin <[EMAIL PROTECTED]> wrote:
>
have an impact) Keep CONFIG_SCHED_DEBUG=y to be able to twiddle the
sysctl.
>> It looks good now! Updated results here:
>> http://devloop.org.uk/documentation/database-performance/Linux-Kernels/Ker
* Antoine Martin <[EMAIL PROTECTED]> wrote:
> >> have an impact) Keep CONFIG_SCHED_DEBUG=y to be able to twiddle the
> >> sysctl.
> It looks good now! Updated results here:
> http://devloop.org.uk/documentation/database-performance/Linux-Kernels/Kernels-ManyThreads-CombinedTests5-10msYield-noload
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Satyam Sharma wrote:
> Hi Antoine, Ingo,
> On 9/14/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>>
>>> hm, could you try the patch below ontop of 2.6.23-rc6 and do:
>>>
>>> echo 1 > /proc/sys/kernel/sched_yi
19 matches
Mail list logo
