On Mon, 2007-12-03 at 11:05 +0100, Ingo Molnar wrote:
> * Zhang, Yanmin <[EMAIL PROTECTED]> wrote:
>
> > Although no source codes of volanoMark, I suspect it calls
> > Thread.sched. volanoMark is a kind of chatroom benchmark. When a
> > client sends out a message, server will send the message to
On Tuesday 04 December 2007 11:30, David Schwartz wrote:
> Perhaps it might be possible to scan for the task at the same static
> priority level that is ready-to-run but last in line among other
> ready-to-run tasks and put it after that task?
Nice level versus posix static priority level debate
On Monday 03 December 2007 22:37, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > given how poorly sched_yield() is/was defined the only "compatible"
> > > solution would be to go back to the old yield code.
> >
> > While it is technically allowed to do anything with SCHED_OTHER
> * Mark Lord <[EMAIL PROTECTED]> wrote:
> > Ack. And what of the suggestion to try to ensure that a yielding task
> > simply not end up as the very next one chosen to run? Maybe by
> > swapping it with another (adjacent?) task in the tree if it comes out
> > on top again?
> we did that too fo
On Tuesday 04 December 2007 09:33, Ingo Molnar wrote:
> * Mark Lord <[EMAIL PROTECTED]> wrote:
> >> heh, thanks :) For which workload does it make the biggest difference
> >> for you? (and compared to what other scheduler you used before?
> >> 2.6.22?)
> >
> > ..
> >
> > Heh.. I'm just a very unsop
* Mark Lord <[EMAIL PROTECTED]> wrote:
>> heh, thanks :) For which workload does it make the biggest difference
>> for you? (and compared to what other scheduler you used before?
>> 2.6.22?)
> ..
>
> Heh.. I'm just a very unsophisticated desktop user, and I like it when
> Thunderbird and Firef
Ingo Molnar wrote:
* Mark Lord <[EMAIL PROTECTED]> wrote:
Ack. And what of the suggestion to try to ensure that a yielding task
simply not end up as the very next one chosen to run? Maybe by
swapping it with another (adjacent?) task in the tree if it comes out
on top again?
we did that to
* Mark Lord <[EMAIL PROTECTED]> wrote:
> Ack. And what of the suggestion to try to ensure that a yielding task
> simply not end up as the very next one chosen to run? Maybe by
> swapping it with another (adjacent?) task in the tree if it comes out
> on top again?
we did that too for quite s
Ingo Molnar wrote:
* Mark Lord <[EMAIL PROTECTED]> wrote:
That's not the same thing at all. I think that David is suggesting
that the reinsertion logic should pretend that the task used up all of
the CPU time it was offered in the slot leading up to the
sched_yield() call.
we have tried thi
* Mark Lord <[EMAIL PROTECTED]> wrote:
> That's not the same thing at all. I think that David is suggesting
> that the reinsertion logic should pretend that the task used up all of
> the CPU time it was offered in the slot leading up to the
> sched_yield() call.
we have tried this too, and th
Chris Friesen wrote:
David Schwartz wrote:
Chris Friesen wrote:
..
The problem is where do we insert the task that is yielding? CFS is
based around a tree structure ordered by time.
We put it exactly where we would have when its timeslice ran out. If
we can
reward it a little bit, that's
David Schwartz wrote:
Chris Friesen wrote:
If CFS really can't support sched_yield's semantics, then it should just
not, and that's that. Return ENOSYS and admit that the behavior sched_yield
is documented to have simply can't be supported by the scheduler.
That's just it though...sched_yie
Chris Friesen wrote:
> David Schwartz wrote:
> > I've asked versions of this question at least three times
> > and never gotten
> > anything approaching a straight answer:
> >
> > 1) What is the current default 'sched_yield' behavior?
> >
> > 2) What is the current alternate 'sched_y
David Schwartz wrote:
I've asked versions of this question at least three times and never
gotten
anything approaching a straight answer:
1) What is the current default 'sched_yield' behavior?
2) What is the current alternate 'sched_yield' behavior?
I'm pretty sure I'v
I've asked versions of this question at least three times and never
gotten
anything approaching a straight answer:
1) What is the current default 'sched_yield' behavior?
2) What is the current alternate 'sched_yield' behavior?
3) Are either of them sensible? Sim
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > given how poorly sched_yield() is/was defined the only "compatible"
> > solution would be to go back to the old yield code.
>
> While it is technically allowed to do anything with SCHED_OTHER class,
> putting the thread to the back of the runnable t
On Monday 03 December 2007 21:33, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > I was just talking about the default because I didn't know the
> > > > reason for the way it was set -- now that I do, we should talk
> > > > about trying to improve the actual code so we don't n
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > I was just talking about the default because I didn't know the
> > > reason for the way it was set -- now that I do, we should talk
> > > about trying to improve the actual code so we don't need 2
> > > defaults.
> >
> > I've got the patch below q
* Zhang, Yanmin <[EMAIL PROTECTED]> wrote:
> > as far as desktop apps such as firefox goes, the exact opposite is
> > true. We had two choices basically: either a "more agressive" yield
> > than before or a "less agressive" yield. Desktop apps were reported
> > to hurt from a "more agressive"
On Monday 03 December 2007 20:57, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > as far as desktop apps such as firefox goes, the exact opposite is
> > > true. We had two choices basically: either a "more agressive" yield
> > > than before or a "less agressive" yield. Desktop a
* Zhang, Yanmin <[EMAIL PROTECTED]> wrote:
> Although no source codes of volanoMark, I suspect it calls
> Thread.sched. volanoMark is a kind of chatroom benchmark. When a
> client sends out a message, server will send the message to all
> clients. I suspect the client calls Thread.yield after
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > as far as desktop apps such as firefox goes, the exact opposite is
> > true. We had two choices basically: either a "more agressive" yield
> > than before or a "less agressive" yield. Desktop apps were reported
> > to hurt from a "more agressive" yi
On Mon, 2007-12-03 at 09:45 +0100, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > On Friday 30 November 2007 21:08, Ingo Molnar wrote:
> > > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > Haven't we been asking JVMs to use futexes or posix locking for years
> > > > and years
On Mon, 2007-12-03 at 20:17 +1100, Nick Piggin wrote:
> On Monday 03 December 2007 19:45, Ingo Molnar wrote:
> > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > On Friday 30 November 2007 21:08, Ingo Molnar wrote:
> > > > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > > Haven't we been asking JVMs
On Fri, 2007-11-30 at 11:08 +0100, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Haven't we been asking JVMs to use futexes or posix locking for years
> > and years now? [...]
>
> i'm curious, with what JVM was it tested and where's the source so i can
> fix their locking
On Monday 03 December 2007 19:45, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > On Friday 30 November 2007 21:08, Ingo Molnar wrote:
> > > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > Haven't we been asking JVMs to use futexes or posix locking for years
> > > > and years now
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Friday 30 November 2007 21:08, Ingo Molnar wrote:
> > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > Haven't we been asking JVMs to use futexes or posix locking for years
> > > and years now? [...]
> >
> > i'm curious, with what JVM was it tested and
On Friday 30 November 2007 21:08, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Haven't we been asking JVMs to use futexes or posix locking for years
> > and years now? [...]
>
> i'm curious, with what JVM was it tested and where's the source so i can
> fix their locking for the
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> Haven't we been asking JVMs to use futexes or posix locking for years
> and years now? [...]
i'm curious, with what JVM was it tested and where's the source so i can
fix their locking for them? Can the problem be reproduced with:
http://download.f
On Fri, 2007-11-30 at 14:29 +1100, Nick Piggin wrote:
> On Friday 30 November 2007 14:15, Zhang, Yanmin wrote:
> > On Fri, 2007-11-30 at 13:46 +1100, Nick Piggin wrote:
> > > On Wednesday 28 November 2007 09:57, Arjan van de Ven wrote:
>
> > > > sounds like a bad idea; volanomark (well, technicall
On Friday 30 November 2007 14:15, Zhang, Yanmin wrote:
> On Fri, 2007-11-30 at 13:46 +1100, Nick Piggin wrote:
> > On Wednesday 28 November 2007 09:57, Arjan van de Ven wrote:
> > > sounds like a bad idea; volanomark (well, technically the jvm behind
> > > it) is abusing sched_yield() by assuming
On Fri, 2007-11-30 at 13:46 +1100, Nick Piggin wrote:
> On Wednesday 28 November 2007 09:57, Arjan van de Ven wrote:
> > On Tue, 27 Nov 2007 17:33:05 +0800
> >
> > "Zhang, Yanmin" <[EMAIL PROTECTED]> wrote:
> > > If echo "1">/proc/sys/kernel/sched_compat_yield before starting
> > > volanoMark testi
On Friday 30 November 2007 13:51, Arjan van de Ven wrote:
> On Fri, 30 Nov 2007 13:46:22 +1100
>
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > Todays kernel has a different behavior somewhat (and before people
> > > scream "regression"; sched_yield() behavior isn't really specified
> > > and doesn
On Fri, 30 Nov 2007 13:46:22 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Todays kernel has a different behavior somewhat (and before people
> > scream "regression"; sched_yield() behavior isn't really specified
> > and doesn't make any sense at all, whatever you get is what you
> > get it
On Wednesday 28 November 2007 09:57, Arjan van de Ven wrote:
> On Tue, 27 Nov 2007 17:33:05 +0800
>
> "Zhang, Yanmin" <[EMAIL PROTECTED]> wrote:
> > If echo "1">/proc/sys/kernel/sched_compat_yield before starting
> > volanoMark testing, the result is very good with kernel 2.6.24-rc3 on
> > my 16-co
On Tue, 27 Nov 2007 17:33:05 +0800
"Zhang, Yanmin" <[EMAIL PROTECTED]> wrote:
> If echo "1">/proc/sys/kernel/sched_compat_yield before starting
> volanoMark testing, the result is very good with kernel 2.6.24-rc3 on
> my 16-core tigerton.
>
> 1) If /proc/sys/kernel/sched_compat_yield=1, comparing
* Zhang, Yanmin <[EMAIL PROTECTED]> wrote:
> If echo "1">/proc/sys/kernel/sched_compat_yield before starting
> volanoMark testing, the result is very good with kernel 2.6.24-rc3 on
> my 16-core tigerton.
yep, that's known and has been discussed in detail on lkml. Java should
use something mor
37 matches
Mail list logo
