On 02/19/2013 12:13 PM, Rakib Mullick wrote:
> On Mon, Feb 18, 2013 at 9:25 PM, Steven Rostedt wrote:
>> On Mon, 2013-02-18 at 13:43 +0530, Srikar Dronamraju wrote:
The cache misses dropped by ~23% and migrations dropped by ~28%. I
really believe that the idle_balance() hurts
On Mon, Feb 18, 2013 at 9:25 PM, Steven Rostedt wrote:
> On Mon, 2013-02-18 at 13:43 +0530, Srikar Dronamraju wrote:
>> > The cache misses dropped by ~23% and migrations dropped by ~28%. I
>> > really believe that the idle_balance() hurts performance, and not just
>> > for something like
On Mon, 2013-02-18 at 10:23 -0500, Steven Rostedt wrote:
> On Mon, 2013-02-18 at 04:42 +0100, Mike Galbraith wrote:
> > On Sun, 2013-02-17 at 16:54 -0500, Steven Rostedt wrote:
> > > On Sun, 2013-02-17 at 08:14 +0100, Mike Galbraith wrote:
> > >
> > > > (And puts a dent in x264 ultrafast)
> >
On Mon, 2013-02-18 at 13:43 +0530, Srikar Dronamraju wrote:
> > The cache misses dropped by ~23% and migrations dropped by ~28%. I
> > really believe that the idle_balance() hurts performance, and not just
> > for something like hackbench, but the aggressive nature for migration
> > that
On Mon, 2013-02-18 at 04:42 +0100, Mike Galbraith wrote:
> On Sun, 2013-02-17 at 16:54 -0500, Steven Rostedt wrote:
> > On Sun, 2013-02-17 at 08:14 +0100, Mike Galbraith wrote:
> >
> > > (And puts a dent in x264 ultrafast)
>
> > What about my last patch? The one that avoids idle_balance() if
> The cache misses dropped by ~23% and migrations dropped by ~28%. I
> really believe that the idle_balance() hurts performance, and not just
> for something like hackbench, but the aggressive nature for migration
> that idle_balance() causes takes a large hit on a process' cache.
>
> Think about
The cache misses dropped by ~23% and migrations dropped by ~28%. I
really believe that the idle_balance() hurts performance, and not just
for something like hackbench, but the aggressive nature for migration
that idle_balance() causes takes a large hit on a process' cache.
Think about it
On Mon, 2013-02-18 at 04:42 +0100, Mike Galbraith wrote:
On Sun, 2013-02-17 at 16:54 -0500, Steven Rostedt wrote:
On Sun, 2013-02-17 at 08:14 +0100, Mike Galbraith wrote:
(And puts a dent in x264 ultrafast)
What about my last patch? The one that avoids idle_balance() if the
On Mon, 2013-02-18 at 13:43 +0530, Srikar Dronamraju wrote:
The cache misses dropped by ~23% and migrations dropped by ~28%. I
really believe that the idle_balance() hurts performance, and not just
for something like hackbench, but the aggressive nature for migration
that idle_balance()
On Mon, 2013-02-18 at 10:23 -0500, Steven Rostedt wrote:
On Mon, 2013-02-18 at 04:42 +0100, Mike Galbraith wrote:
On Sun, 2013-02-17 at 16:54 -0500, Steven Rostedt wrote:
On Sun, 2013-02-17 at 08:14 +0100, Mike Galbraith wrote:
(And puts a dent in x264 ultrafast)
What about
On Mon, Feb 18, 2013 at 9:25 PM, Steven Rostedt rost...@goodmis.org wrote:
On Mon, 2013-02-18 at 13:43 +0530, Srikar Dronamraju wrote:
The cache misses dropped by ~23% and migrations dropped by ~28%. I
really believe that the idle_balance() hurts performance, and not just
for something like
On 02/19/2013 12:13 PM, Rakib Mullick wrote:
On Mon, Feb 18, 2013 at 9:25 PM, Steven Rostedt rost...@goodmis.org wrote:
On Mon, 2013-02-18 at 13:43 +0530, Srikar Dronamraju wrote:
The cache misses dropped by ~23% and migrations dropped by ~28%. I
really believe that the idle_balance() hurts
On Sun, 2013-02-17 at 16:54 -0500, Steven Rostedt wrote:
> On Sun, 2013-02-17 at 08:14 +0100, Mike Galbraith wrote:
>
> > (And puts a dent in x264 ultrafast)
> What about my last patch? The one that avoids idle_balance() if the
> previous task was in a task_uninterruptible state. That one gave
On Sun, 2013-02-17 at 08:14 +0100, Mike Galbraith wrote:
> (And puts a dent in x264 ultrafast)
>
> +SD_BALANCE_NEWIDLE
> encoded 600 frames, 425.04 fps, 22132.71 kb/s
> encoded 600 frames, 416.07 fps, 22132.71 kb/s
> encoded 600 frames, 417.49 fps, 22132.71 kb/s
> encoded 600 frames, 420.65 fps,
On Sun, 2013-02-17 at 08:14 +0100, Mike Galbraith wrote:
(And puts a dent in x264 ultrafast)
+SD_BALANCE_NEWIDLE
encoded 600 frames, 425.04 fps, 22132.71 kb/s
encoded 600 frames, 416.07 fps, 22132.71 kb/s
encoded 600 frames, 417.49 fps, 22132.71 kb/s
encoded 600 frames, 420.65 fps,
On Sun, 2013-02-17 at 16:54 -0500, Steven Rostedt wrote:
On Sun, 2013-02-17 at 08:14 +0100, Mike Galbraith wrote:
(And puts a dent in x264 ultrafast)
What about my last patch? The one that avoids idle_balance() if the
previous task was in a task_uninterruptible state. That one gave the
On Sun, 2013-02-17 at 07:26 +0100, Mike Galbraith wrote:
> On Sat, 2013-02-16 at 11:12 -0500, Steven Rostedt wrote:
> > On Fri, 2013-02-15 at 08:26 +0100, Mike Galbraith wrote:
> > > On Fri, 2013-02-15 at 01:13 -0500, Steven Rostedt wrote:
> > >
> > > > Think about it some more, just because we
On Fri, 2013-02-15 at 01:13 -0500, Steven Rostedt wrote:
> I've been working on cleaning up the scheduler a little and I moved the
> call to idle_balance() from directly in the scheduler proper into the
> idle class. Benchmarks (well hackbench) improved slightly as I did this.
> I was adding some
On Sat, 2013-02-16 at 11:12 -0500, Steven Rostedt wrote:
> On Fri, 2013-02-15 at 08:26 +0100, Mike Galbraith wrote:
> > On Fri, 2013-02-15 at 01:13 -0500, Steven Rostedt wrote:
> >
> > > Think about it some more, just because we go idle isn't enough reason to
> > > pull a runable task over. CPUs
On Fri, 2013-02-15 at 08:26 +0100, Mike Galbraith wrote:
> On Fri, 2013-02-15 at 01:13 -0500, Steven Rostedt wrote:
>
> > Think about it some more, just because we go idle isn't enough reason to
> > pull a runable task over. CPUs go idle all the time, and tasks are woken
> > up all the time.
On Fri, 2013-02-15 at 08:26 +0100, Mike Galbraith wrote:
On Fri, 2013-02-15 at 01:13 -0500, Steven Rostedt wrote:
Think about it some more, just because we go idle isn't enough reason to
pull a runable task over. CPUs go idle all the time, and tasks are woken
up all the time. There's no
On Sat, 2013-02-16 at 11:12 -0500, Steven Rostedt wrote:
On Fri, 2013-02-15 at 08:26 +0100, Mike Galbraith wrote:
On Fri, 2013-02-15 at 01:13 -0500, Steven Rostedt wrote:
Think about it some more, just because we go idle isn't enough reason to
pull a runable task over. CPUs go idle all
On Fri, 2013-02-15 at 01:13 -0500, Steven Rostedt wrote:
I've been working on cleaning up the scheduler a little and I moved the
call to idle_balance() from directly in the scheduler proper into the
idle class. Benchmarks (well hackbench) improved slightly as I did this.
I was adding some
On Sun, 2013-02-17 at 07:26 +0100, Mike Galbraith wrote:
On Sat, 2013-02-16 at 11:12 -0500, Steven Rostedt wrote:
On Fri, 2013-02-15 at 08:26 +0100, Mike Galbraith wrote:
On Fri, 2013-02-15 at 01:13 -0500, Steven Rostedt wrote:
Think about it some more, just because we go idle isn't
On Fri, 2013-02-15 at 16:45 +0900, Joonsoo Kim wrote:
> Hello, Steven.
> - Before Patch
> Permance counter stats for 'perf bench sched messaging -g 300' (10 runs):
>
> 40847.488740 task-clock#3.232 CPUs utilized
>( +- 1.24% )
>511,070
On Fri, 2013-02-15 at 13:21 +0100, Peter Zijlstra wrote:
> On Fri, 2013-02-15 at 08:26 +0100, Mike Galbraith wrote:
> >
> > (the throttle is supposed to keep idle_balance() from doing severe
> > damage, that may want a peek/tweak)
>
> Right, as it stands idle_balance() can do a lot of work and
On Fri, 2013-02-15 at 08:26 +0100, Mike Galbraith wrote:
>
> (the throttle is supposed to keep idle_balance() from doing severe
> damage, that may want a peek/tweak)
Right, as it stands idle_balance() can do a lot of work and if the avg
idle time is less than the time we spend looking for a
On Fri, 2013-02-15 at 08:26 +0100, Mike Galbraith wrote:
>
> (the throttle is supposed to keep idle_balance() from doing severe
> damage, that may want a peek/tweak)
Right, as it stands idle_balance() can do a lot of work and if the avg
idle time is less than the time we spend looking for a
On Fri, 2013-02-15 at 08:26 +0100, Mike Galbraith wrote:
(the throttle is supposed to keep idle_balance() from doing severe
damage, that may want a peek/tweak)
Right, as it stands idle_balance() can do a lot of work and if the avg
idle time is less than the time we spend looking for a
On Fri, 2013-02-15 at 08:26 +0100, Mike Galbraith wrote:
(the throttle is supposed to keep idle_balance() from doing severe
damage, that may want a peek/tweak)
Right, as it stands idle_balance() can do a lot of work and if the avg
idle time is less than the time we spend looking for a
On Fri, 2013-02-15 at 13:21 +0100, Peter Zijlstra wrote:
On Fri, 2013-02-15 at 08:26 +0100, Mike Galbraith wrote:
(the throttle is supposed to keep idle_balance() from doing severe
damage, that may want a peek/tweak)
Right, as it stands idle_balance() can do a lot of work and if the
On Fri, 2013-02-15 at 16:45 +0900, Joonsoo Kim wrote:
Hello, Steven.
- Before Patch
Permance counter stats for 'perf bench sched messaging -g 300' (10 runs):
40847.488740 task-clock#3.232 CPUs utilized
( +- 1.24% )
511,070 context-switches
Hello, Steven.
On Fri, Feb 15, 2013 at 01:13:39AM -0500, Steven Rostedt wrote:
> Performance counter stats for '/work/c/hackbench 500' (100 runs):
>
> 199820.045583 task-clock#8.016 CPUs utilized
>( +- 5.29% ) [100.00%]
> 3,594,264
On Fri, 2013-02-15 at 01:13 -0500, Steven Rostedt wrote:
> Think about it some more, just because we go idle isn't enough reason to
> pull a runable task over. CPUs go idle all the time, and tasks are woken
> up all the time. There's no reason that we can't just wait for the sched
> tick to
I've been working on cleaning up the scheduler a little and I moved the
call to idle_balance() from directly in the scheduler proper into the
idle class. Benchmarks (well hackbench) improved slightly as I did this.
I was adding some more tweaks and running perf stat on the results when
I made a
I've been working on cleaning up the scheduler a little and I moved the
call to idle_balance() from directly in the scheduler proper into the
idle class. Benchmarks (well hackbench) improved slightly as I did this.
I was adding some more tweaks and running perf stat on the results when
I made a
On Fri, 2013-02-15 at 01:13 -0500, Steven Rostedt wrote:
Think about it some more, just because we go idle isn't enough reason to
pull a runable task over. CPUs go idle all the time, and tasks are woken
up all the time. There's no reason that we can't just wait for the sched
tick to decide
Hello, Steven.
On Fri, Feb 15, 2013 at 01:13:39AM -0500, Steven Rostedt wrote:
Performance counter stats for '/work/c/hackbench 500' (100 runs):
199820.045583 task-clock#8.016 CPUs utilized
( +- 5.29% ) [100.00%]
3,594,264 context-switches
38 matches
Mail list logo
