Various scheduler-related topics [LWN.net]

Various scheduler-related topics

Posted Sep 17, 2009 11:45 UTC (Thu) by hppnq (guest, #14462)
Parent article: Various scheduler-related topics

There is a good reason to run the parent first, though: the parent's state is active in the processor, the translation lookaside buffer (TLB) contains the right information, etc. So parent-runs-first should perform better. It appears that recent tests showed that parent-runs-first does, indeed, outperform child-runs-first on that most important benchmark: kernel builds. That was enough to get the default changed.

Ah, nostalgia... Here -- scroll down a bit -- the idea to run the child first was introduced, thinking that this would improve performance in many common cases, because it prevented unnecessary COWs when the child would not do very complicated things. Of course, Linus seemed to use lmbench instead of kernel builds. ;-)

Also, ESR released CML2-1.2.0!

(Log in to post comments)

Various scheduler-related topics

Posted Sep 18, 2009 7:12 UTC (Fri) by mingo (subscriber, #31122) [Link]

Unless things have changed in 8 years, of course.

Two fundamental things have changed.

Firstly, we have an increase in parallelism on the hardware level (more hardware threads, more cores, more sockets) - so pushing child tasks away to other CPUs is generally a good idea.

Secondly, back then in the 2.4 heydays we also didnt have proper vfork() yet. vfork() will in essence guarantee child-runs-first via an explicit handshake between parent and the exec()-ing child. (regardless of the sysctl_sched_child_runs_first control.) That's faster and more efficient than any heuristics the scheduler can provide in this area.

Various scheduler-related topics

Posted Sep 24, 2009 8:33 UTC (Thu) by renox (subscriber, #23785) [Link]

Erm, the vfork manpage comment "It is rather unfortunate that Linux revived this spectre from the past." isn't very motivating for application developers to use vfork..

I think that the API is faulty here: whether it is forking or sending a message, the application developers know if they would prefer scheduling immediately the child/target process or not, so the API should allow the developer to say what he prefers instead of relying on one global default.

Various scheduler-related topics

Posted Sep 18, 2009 7:37 UTC (Fri) by Kamilion (subscriber, #42576) [Link]

Could be the whole SMP-gone-mainstream thing... ;)
The x86 architecture has gone through some interesting permutations since 2001.

*sigh* I remember kernel 2.4.4... Wrestling with going from Slink to Potato and ReiserFS in 2.4.6 going haywire... The install discs still have a warm place in my big CD binder of Linux CDs going back to The Linux System Administrator's Survival Guide's Slackware 3.0 pack-in from 1996.

We've come so far. B-tree filesystems (B+TRee now) are hip again, gentoo's visibly early console/splash work has paved the way for xsplash, 1.6ghz chips have become a hot item again, and we're finally at the point where 256GB SSDs are competing with the 250GB Hard Drives everyone was awestruck with years ago. Good times.