Messages in this thread |  | | From | Davide Libenzi <> | Date | Thu, 18 Jan 2001 17:38:30 -0800 | Subject | Re: multi-queue scheduler update |
| |
On Thursday 18 January 2001 17:33, Mike Kravetz wrote: > On Fri, Jan 19, 2001 at 02:08:52AM +0100, Andi Kleen wrote: > > On Thu, Jan 18, 2001 at 08:00:16PM -0500, Mark Hahn wrote: > > > > > microseconds/yield > > > > > # threads 2.2.16-22 2.4 2.4-multi-queue > > > > > ------------ --------- -------- --------------- > > > > > 16 18.740 4.603 1.455 > > > > > > > > I remeber the O(1) scheduler from Davide Libenzi was beating the > > > > mainline O(N) > > > > > > isn't the normal case (as in "The Right Case to optimize") > > > where there are close to zero runnable tasks? what realistic/sane > > > scenarios have very large numbers of spinning threads? all server > > > situations I can think of do not. not volanomark -loopback, surely! > > > > I think the main point of Mike's patch is decreasing locking and cache > > line bouncing overhead of multi cpu scheduling, not optimizing lots of > > runnable tasks. > > > > > > -Andi > > Andi is correct. Although the results I posted may seem to indicate > we are concentrating on high thread counts, this is really secondary > to reducing lock contention within the scheduler. A co-worker down > the hall just ran pgbench (a postgresql db) benchmark and saw > contention on the runqueue lock at 57%. Now, I know nothing about this > benchmark, but it will be interesting to see what happens after > applying my patch.
Yep, the patch work in a different way and if these are the numbers it seems to be interesting. Could You post results for a fewer number of tasks ? I mean what is the performance loss for 1,2,..,5 tasks ?
To test You can use lmbench ( I don't remember the link ) and I should have the program I've used to test my patch somewhere.
- Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |