On Sunday 16 April 2006 06:45, Al Boldi wrote:
> Con Kolivas wrote:
> > Thanks for bringing this to my attention. A while back I had different
> > management of forked tasks and merged it with PF_NONSLEEP. Since then
> > I've changed the management of NONSLEEP tasks and didn't realise it had
> > adversely affected the accounting of forking tasks. This patch should
> > rectify it.
>
> Congrats!
>
> Much smoother, but I still get this choke w/ 2 eatm 9999 loops running:
> 9 MB 783 KB eaten in 130 msec (74 MB/s)
> 9 MB 783 KB eaten in 2416 msec (3 MB/s) <<<<<<<<<<<<<
> 9 MB 783 KB eaten in 197 msec (48 MB/s)
> You may have to adjust the kb to get the same effect.
I've seen it. It's an artefact of timekeeping that it takes an accumulation of
data to get all the information. Not much I can do about it except to have
timeslices so small that they thrash the crap out of cpu caches and
completely destroy throughput.
The current value, 6ms at 1000HZ, is chosen because it's the largest value
that can schedule a task in less than normal human perceptible range when two
competing heavily cpu bound tasks are the same priority. At 250HZ it works
out to 7.5ms and 10ms at 100HZ. Ironically in my experimenting I found the
cpu cache improvements become much less significant above 7ms so I'm very
happy with this compromise.
Thanks!
--
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
