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.)
Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds