Messages in this thread | | | Subject | Re: [PATCH][GIT PULL] sched/cpupri: Remove the vec->lock | From | Steven Rostedt <> | Date | Wed, 03 Aug 2011 10:49:56 -0400 |
| |
On Wed, 2011-08-03 at 22:18 +0800, Hillf Danton wrote: > On Wed, Aug 3, 2011 at 4:36 AM, Steven Rostedt <rostedt@goodmis.org> wrote: > > The migrate code does stress the RT tasks a bit. This shows that > > the loop did increase a little after the patch, but not by much. > > The vec code dropped dramatically. From 4.3us down to .42us. > > That's a 10x improvement! > > > > Tested-by: Mike Galbraith <mgalbraith@suse.de> > > Tested-by: Luis Claudio R. Gonçalves <lgoncalv@redhat.com> > > Tested-by: Matthew Hank Sabins<msabins@linux.vnet.ibm.com> > > Reviewed-by: Gregory Haskins <gregory.haskins@gmail.com> > > Signed-off-by: Steven Rostedt <rostedt@goodmis.org> > > > Acked-by: Hillf Danton <dhillf@gmail.com>
Hi Hillf,
Thanks for the ack. But I want to point out this change as something I want you to see. Remember when I replied to you with your patches asking about benchmarks and timings and other tests? This patch is a good example of what I meant.
I made a change that looked obvious. But obvious is not good enough when you are dealing with the Linux scheduler. Before posting it, I created a timing patch to record the timings of the affected area for any work load. I then passed this patch with the timing changes to various people that reported issues with this part of the code. I also ran on my own boxes.
The result was outstanding. That is, everyone that reported back to me found improvements and no regressions. The improvements were not just in the timing measurements that I included, but also with their own tests.
Now I'm comfortable with this change.
You sent several patches to me that modified the scheduler in non trivial ways, with no benchmarks or tests attached. Before making any changes to the scheduler, you need to have something that shows that those changes improve things and do not cause regressions.
I sent these patches out over a month ago to get these results. I'm putting this change in for v3.2, that way it can get even more testing in linux-next to make sure we didn't miss anything.
This is what I want you to understand. That the scheduler is a core aspect of Linux, and if we mess it up, it will affect everyone. We can't take that lightly.
Thanks!
-- Steve
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |