| |||||||||||||
Various scheduler-related topicsVarious scheduler-related topicsPosted Sep 18, 2009 7:12 UTC (Fri) by mingo (subscriber, #31122)In reply to: Various scheduler-related topics by jimparis Parent article: Various scheduler-related topics
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.
(Log in to post comments)
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.
|
|||||||||||||