> >> N.Threads 2.3.5 MyPatch Diff
> >>
> >> 2 700000 600000 -15 %
> >> 10 280000 365000 +25 %
> >> 450 6100 8900 +45 %
>
> >this is what i suspected. If we are switching 450 threads that also do
> >some real work then we are trashing the cache _badly_ already, so pure
> >scheduling costs will not matter at all. Most systems (even loaded
> >servers) have typically less than 5 runnable processes. So those systems
> >will see 15% scheduling slowdown. Some applications might use many threads
> >- for those cases your patch is a nice improvement.
>
> Sorry, but are we building a new version of MS-DOS here ???
>
> Linux is well known as good server platform and You want to say me that
> more of Linux users will fall the 2 thread case ??!?!
Something like that - and I agree, nearly all the machines I admin
tend to have <5 runnable processes on them.
> In a schedule() algo filled of gotos to get a better prefetch queue that can
> improve speed no more then 10 % I post a patch that on tipical Linux machines
> will lead to a 30 up to 80 % of increasing performance.
I don't think 450 runnable processes is typical of any machine I've ever
seen. Even with 10 processes really trying to do anything, most machines
will be trashing their caches, and maybe swapping, etc. Your patch will
likely decrease performance on every machine I admin (about 40 machines).
> Now one of the two things must be true:
>
> 1) I'm crazy
> 2) I'm in the wrong place
I think you are just mistaken about the number of processes running on
most boxes, and that scheduling faster will just get lost in the noise on
a machine that really has several hundred processes running...
later,
Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/