Czy planista linuksowy woli uruchamiać proces potomny po fork()?

Question

Czy program planujący Linuksa woli uruchamiać proces potomny po fork() w procesie ojca?

Zwykle rozwidlony proces będzie wykonywał exec, więc lepiej, aby proces potomny działał przed procesem ojca (aby zapobiec kopiowaniu przy zapisie).

Zakładam, że dziecko wykona exec jako pierwszą operację po jej utworzeniu.

Czy moje założenie (że program planujący preferuje proces potomny) jest prawidłowe. Jeśli nie, dlaczego? Jeśli tak, to czy istnieje więcej powodów, aby najpierw uruchomić dziecko?

Answer 1

Cytując The Linux Programming Interface (pg. 525) na ogólną odpowiedź:

Po fork() jest nieokreślona, ​​który proces - rodzic lub dziecko - obok ma dostęp do procesora. (W systemach wieloprocesorowych, mogą one zarówno jednocześnie uzyskać dostęp do CPU.)

Książka idzie o różnice w wersjach jądra, a także wspomina CFS/Linux 2.6.32:

[ ...] od Linuksa 2.6.32, jest po raz kolejny rodzicem, domyślnie uruchamianym najpierw po fork(). To ustawienie domyślne można zmienić, przypisując niezerową wartość do specyficznego dla systemu Linux pliku /proc/sys/kernel/sched_child_runs_first.

This behaviour is still present with CFS mimo że istnieją some concerns dla przyszłości tej funkcji. Patrząc na implementację CFS, ona jest rodzicem przed dzieckiem.

Aby uzyskać dostęp, należy ustawić wartość /proc/sys/kernel/sched_child_runs_first na wartość niezerową.

Edytuj:This answer analizuje zachowanie domyślne i porównuje je z sched_child_runs_first.

Answer 2

W przypadku, gdy dziecko dzwoni pod numer exec, przy pierwszej okazji można zamiast widelca użyć vfork. vfork zawiesza rodzica, dopóki dziecko nie zadzwoni pod numer _exit lub exec *. Jednak po wywołaniu exec dziecko zostanie zawieszone, jeśli kod musi zostać załadowany z dysku. W takim przypadku rodzic ma dużą szansę na kontynuację, zanim dziecko to zrobi.