User: Password:
|
|
Subscribe / Log in / New account

Some notes from the BFS discussion - and Con Kolivas responded...

Some notes from the BFS discussion - and Con Kolivas responded...

Posted Sep 10, 2009 15:54 UTC (Thu) by mingo (subscriber, #31122)
In reply to: Some notes from the BFS discussion - and Con Kolivas responded... by Tracey
Parent article: Some notes from the BFS discussion

Anyway, here's the real funny part: After I would set the scheduler parameters lower I "noticed" that the screen was smoother and more responsive. Totally subjective on my part. Of course, it was very late and I needed sleep.

That's very much possible. The upstream scheduler is a deadline scheduler in essence, and /proc/sys/kernel/sched_latency_ns sets the latency target. The scheduler tries to schedules tasks so that no task ever gets a longer delay than this latency target. (i.e. no task misses its deadline)

The defaults on 2.6.31 are 20 msecs for 1-CPU systems, 40 msecs for 2-CPU systems and 60 msecs for 4-CPU systems (etc. - growing logarithmically by CPU count).

Smaller value there means more scheduling - but also faster reaction and 'smoother' mixing of workloads. So if you lower your 40 msecs down to 20 msecs, you could get a "two times smoother" visual experience for certain GUI workloads.

You can think of it as if your 50 Hz flickering screen went to 100 Hz by halving its latency target. Such changes can affect the subjective end result rather spectacularly.

It would be nice if you documented your latency parameter changes so that we could consider them for the mainline scheduler. Those parameters were always meant to be (and were regularly) tweaked and its effects were re-measured.

The latest scheduler tree (the 2.6.32 scheduler bits) also has them lowered - you can test it by booting the -tip kernel.

Does the -tip tree feel more interactive to you, or do you still need to lower the latency targets there too?

(Feel free to report it in email or here on LWN.net.)


(Log in to post comments)

Some notes from the BFS discussion - and Con Kolivas responded...

Posted Sep 17, 2009 6:34 UTC (Thu) by eduperez (guest, #11232) [Link]

The defaults on 2.6.31 are 20 msecs for 1-CPU systems, 40 msecs for 2-CPU systems and 60 msecs for 4-CPU systems (etc. - growing logarithmically by CPU count).

From my complete ignorance of how it works, may I ask why? This seems counter-intuitive to me: as the number of CPU's increase, users expect to feel a lower latency; and having more CPU's means the scheduler has it easier to find and empty CPU where the delayed task can execute. Thanks.

Some notes from the BFS discussion - and Con Kolivas responded...

Posted Sep 17, 2009 16:44 UTC (Thu) by dlang (subscriber, #313) [Link]

shorter time slices are inefficient (remember cache is many times faster than ram) so with more CPUs you can let the per-cpu latency creep higher and get equivalent or better overall responsiveness due to the additional CPUs being available to do the work.

Some notes from the BFS discussion - and Con Kolivas responded...

Posted Sep 21, 2009 12:56 UTC (Mon) by eduperez (guest, #11232) [Link]

per-cpu!!!
I did not notice that those latencies where _per-cpu_, and (wrongly) assumed they where _global_...; it makes a lot more sense, now; thanks.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds