[lkml]   [2003]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6.0-test3-mm1
On Tue, 12 Aug 2003 00:35, Martin J. Bligh wrote:
> Degredation on kernbench is still there:
> Kernbench: (make -j N vmlinux, where N = 16 x num_cpus)
> Elapsed System User CPU
> 2.6.0-test3 45.97 115.83 571.93 1494.50
> 2.6.0-test3-mm1 46.43 122.78 571.87 1496.00
> Quite a bit of extra sys time. I thought the suspected part of the sched
> changes got backed out, but maybe I'm just not following it ...

It was plus and minus. I've improved my hacks, but the A3 patch nanosecond
timing will add extra overhead/locking. I'm not sure how you can compare
these to the last ones you posted:

Elapsed System User CPU
2.6.0-test2 46.05 115.20 571.75 1491.25
2.6.0-test2-con 46.98 121.02 583.55 1498.75
2.6.0-test2-mm1 46.95 121.18 582.00 1497.50

I'll take a stab in the dark and say the nanosecond timing is a big part now.
Backing out all the O*int patches in broken-out of 2.6.0-test3-mm1 should
help identify that.

I have an idea on how to trim the nanosecond overhead as well. The sched clock
should be called if the timing is less than say two jiffies only. That will
mean it will be called far less frequently.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.120 / U:1.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site