Um agendador de processos Unix não é realmente "piggy back" em uma chamada de sistema. A execução do agendador faz parte de praticamente qualquer chamada de sistema.
Uma chamada de sistema read() ou uma chamada de sistema exit() tem absolutamente que fazer com que o agendador seja executado. No caso de um read() , um acesso ao disco pode levar muito tempo. A menos que você queira que tudo fique muito lento, você precisa executar o agendador para ver qual processo deve ser executado enquanto o primeiro processo espera que o disco retorne com dados. Um read() pode acontecer em um soquete - o tempo que leva para os dados retornarem de algum servidor remoto é indeterminado. O kernel deve reprogramar algum outro processo. No caso de um exit() , o processo que faz a chamada do sistema não deseja mais existir, portanto, algum outro processo deve ser planejado. Para um pause() ou um alarm() , o processo deseja executar algum tempo no futuro. Novamente, o agendador precisa escolher outro processo para executar.
Acredito que a maioria das chamadas de sistema, mas não todas, fazem com que o programador Unix / Linux / * BSD seja executado. Às vezes, gettimeofday() não faz com que o agendador seja executado - o Solaris costumava funcionar dessa maneira. Mas, em geral, você pode pensar com segurança em uma chamada do sistema executando o trabalho (enviando dados pela NIC, configurando uma leitura ou gravação em disco, fazendo o trabalho de saída do processo, bifurcando, etc.), executando o agendador e executando qualquer o processo deve ser executado em seguida. Às vezes, esse é o mesmo processo que fez a chamada do sistema, mas na maior parte do tempo, não é.