On Mon, Jul 30, 2007 at 05:07:46PM -0400, Chris Snook wrote:
> [..] It's spending a lot less time in %sys despite the
> higher context switches, [..]
The workload takes 40% more so you've to add up that additional 40%
too into your math. "A lot less time" sounds an overstatement to
me. Also
Tim Chen wrote:
On Sat, 2007-07-28 at 02:51 -0400, Chris Snook wrote:
Tim --
Since you're already set up to do this benchmarking, would you mind
varying the parameters a bit and collecting vmstat data? If you want to
run oprofile too, that wouldn't hurt.
Here's the vmstat data. The
On Sat, 2007-07-28 at 02:51 -0400, Chris Snook wrote:
>
> Tim --
>
> Since you're already set up to do this benchmarking, would you mind
> varying the parameters a bit and collecting vmstat data? If you want to
> run oprofile too, that wouldn't hurt.
>
Here's the vmstat data. The
On Sat, 2007-07-28 at 02:51 -0400, Chris Snook wrote:
Tim --
Since you're already set up to do this benchmarking, would you mind
varying the parameters a bit and collecting vmstat data? If you want to
run oprofile too, that wouldn't hurt.
Here's the vmstat data. The number of
Tim Chen wrote:
On Sat, 2007-07-28 at 02:51 -0400, Chris Snook wrote:
Tim --
Since you're already set up to do this benchmarking, would you mind
varying the parameters a bit and collecting vmstat data? If you want to
run oprofile too, that wouldn't hurt.
Here's the vmstat data. The
On Mon, Jul 30, 2007 at 05:07:46PM -0400, Chris Snook wrote:
[..] It's spending a lot less time in %sys despite the
higher context switches, [..]
The workload takes 40% more so you've to add up that additional 40%
too into your math. A lot less time sounds an overstatement to
me. Also you've
On Fri, Jul 27, 2007 at 10:47:21PM -0400, Rik van Riel wrote:
> Tim Chen wrote:
> > Ingo,
> >
> > Volanomark slows by 80% with CFS scheduler on 2.6.23-rc1.
> > Benchmark was run on a 2 socket Core2 machine.
> >
> > The change in scheduler treatment of sched_yield
> > could play a part
> > Volanomark runs better
> > and is only 40% (instead of 80%) down from old scheduler
> > without CFS.
> 40 or 80 % is still a huge regression.
> Dmitry Adamushko
Can anyone explain precisely what Volanomark is doing? If it's something
dumb like "looping on sched_yield until the 'right'
On 28/07/07, Chris Snook <[EMAIL PROTECTED]> wrote:
> [ ... ]
> Under CFS, the yielding process will still be leftmost in the rbtree,
> otherwise it would have already been scheduled out.
Not actually true. The position of the 'current' task within the
rb-tree is updated with a timer tick's
On 28/07/07, Tim Chen <[EMAIL PROTECTED]> wrote:
> [ ... ]
> It may make sense to queue the
> yielding process a bit further behind in the queue.
> I made a slight change by zeroing out wait_runtime
> (i.e. have the process gives
> up cpu time due for it to run) for experimentation.
But that's
Andrea Arcangeli wrote:
On Fri, Jul 27, 2007 at 11:43:23PM -0400, Chris Snook wrote:
I'm pretty sure the point of posting a patch that triples CFS performance
on a certain benchmark and arguably improves the semantics of sched_yield
was to improve CFS. You have a point, but it is a point for
Andrea Arcangeli wrote:
On Fri, Jul 27, 2007 at 11:43:23PM -0400, Chris Snook wrote:
I'm pretty sure the point of posting a patch that triples CFS performance
on a certain benchmark and arguably improves the semantics of sched_yield
was to improve CFS. You have a point, but it is a point for
On 28/07/07, Tim Chen [EMAIL PROTECTED] wrote:
[ ... ]
It may make sense to queue the
yielding process a bit further behind in the queue.
I made a slight change by zeroing out wait_runtime
(i.e. have the process gives
up cpu time due for it to run) for experimentation.
But that's wrong. The
On 28/07/07, Chris Snook [EMAIL PROTECTED] wrote:
[ ... ]
Under CFS, the yielding process will still be leftmost in the rbtree,
otherwise it would have already been scheduled out.
Not actually true. The position of the 'current' task within the
rb-tree is updated with a timer tick's
Volanomark runs better
and is only 40% (instead of 80%) down from old scheduler
without CFS.
40 or 80 % is still a huge regression.
Dmitry Adamushko
Can anyone explain precisely what Volanomark is doing? If it's something
dumb like looping on sched_yield until the 'right' thread runs
On Fri, Jul 27, 2007 at 10:47:21PM -0400, Rik van Riel wrote:
Tim Chen wrote:
Ingo,
Volanomark slows by 80% with CFS scheduler on 2.6.23-rc1.
Benchmark was run on a 2 socket Core2 machine.
The change in scheduler treatment of sched_yield
could play a part in changing
On Fri, Jul 27, 2007 at 11:43:23PM -0400, Chris Snook wrote:
> I'm pretty sure the point of posting a patch that triples CFS performance
> on a certain benchmark and arguably improves the semantics of sched_yield
> was to improve CFS. You have a point, but it is a point for a different
>
Andrea Arcangeli wrote:
On Fri, Jul 27, 2007 at 08:31:19PM -0400, Chris Snook wrote:
I think Volanomark is being pretty stupid, and deserves to run slowly, but
Indeed, any app doing what volanomark does is pretty inefficient.
But this is not the point. I/O schedulers are pluggable to help
Tim Chen wrote:
Ingo,
Volanomark slows by 80% with CFS scheduler on 2.6.23-rc1.
Benchmark was run on a 2 socket Core2 machine.
The change in scheduler treatment of sched_yield
could play a part in changing Volanomark behavior.
In CFS, sched_yield is implemented
by dequeueing and
On Fri, Jul 27, 2007 at 08:31:19PM -0400, Chris Snook wrote:
> I think Volanomark is being pretty stupid, and deserves to run slowly, but
Indeed, any app doing what volanomark does is pretty inefficient.
But this is not the point. I/O schedulers are pluggable to help for
inefficient apps too.
Tim Chen wrote:
Ingo,
Volanomark slows by 80% with CFS scheduler on 2.6.23-rc1.
Benchmark was run on a 2 socket Core2 machine.
The change in scheduler treatment of sched_yield
could play a part in changing Volanomark behavior.
In CFS, sched_yield is implemented
by dequeueing and
Ingo,
Volanomark slows by 80% with CFS scheduler on 2.6.23-rc1.
Benchmark was run on a 2 socket Core2 machine.
The change in scheduler treatment of sched_yield
could play a part in changing Volanomark behavior.
In CFS, sched_yield is implemented
by dequeueing and requeueing a process . The
Ingo,
Volanomark slows by 80% with CFS scheduler on 2.6.23-rc1.
Benchmark was run on a 2 socket Core2 machine.
The change in scheduler treatment of sched_yield
could play a part in changing Volanomark behavior.
In CFS, sched_yield is implemented
by dequeueing and requeueing a process . The
Tim Chen wrote:
Ingo,
Volanomark slows by 80% with CFS scheduler on 2.6.23-rc1.
Benchmark was run on a 2 socket Core2 machine.
The change in scheduler treatment of sched_yield
could play a part in changing Volanomark behavior.
In CFS, sched_yield is implemented
by dequeueing and
On Fri, Jul 27, 2007 at 08:31:19PM -0400, Chris Snook wrote:
I think Volanomark is being pretty stupid, and deserves to run slowly, but
Indeed, any app doing what volanomark does is pretty inefficient.
But this is not the point. I/O schedulers are pluggable to help for
inefficient apps too. If
Tim Chen wrote:
Ingo,
Volanomark slows by 80% with CFS scheduler on 2.6.23-rc1.
Benchmark was run on a 2 socket Core2 machine.
The change in scheduler treatment of sched_yield
could play a part in changing Volanomark behavior.
In CFS, sched_yield is implemented
by dequeueing and
Andrea Arcangeli wrote:
On Fri, Jul 27, 2007 at 08:31:19PM -0400, Chris Snook wrote:
I think Volanomark is being pretty stupid, and deserves to run slowly, but
Indeed, any app doing what volanomark does is pretty inefficient.
But this is not the point. I/O schedulers are pluggable to help
On Fri, Jul 27, 2007 at 11:43:23PM -0400, Chris Snook wrote:
I'm pretty sure the point of posting a patch that triples CFS performance
on a certain benchmark and arguably improves the semantics of sched_yield
was to improve CFS. You have a point, but it is a point for a different
thread.
28 matches
Mail list logo
