From: Tomas Hruby <tom@minix3.org>
Date: Sat, 10 Apr 2010 15:27:38 +0000 (+0000)
Subject: Quantum in fork
X-Git-Tag: v3.1.7~157
X-Git-Url: http://zhaoyanbai.com/repos/%22http:/www.isc.org/icons/man.named.html?a=commitdiff_plain;h=9b599bac1d3f9f919ae5ab39a3db1e49c7b9aab7;p=minix.git

Quantum in fork

- This patch removes the time slice split between parent and child in
  fork.

- The time slice of the parent remains unchanged and the child does
  not have any.

- If the process has a scheduler, the scheduler must assign the
  quantum and priority of the new process and let it run.

- If the child does not inherit a scheduler, it is scheduled by the
  dummy default kernel policy. (servers, drivers, etc.)

- In theory, the scheduler can change the quantum even of the parent
  process and implement any policy for splitting the quantum as
  neither the parent nor the child are runnable.  Sending the
  out-of_quantum message on behalf of the processes may look like the
  right solution, however, the scheduler would probably handle the
  message before the whole fork protocol is finished. This way the
  scheduler has absolute control when the process should become
  runnable.
---

diff --git a/kernel/system/do_fork.c b/kernel/system/do_fork.c
index d66f6fcde..936df8f5a 100644
--- a/kernel/system/do_fork.c
+++ b/kernel/system/do_fork.c
@@ -80,25 +80,14 @@ PUBLIC int do_fork(struct proc * caller, message * m_ptr)
   rpc->p_virt_left = 0;		/* disable, clear the process-virtual timers */
   rpc->p_prof_left = 0;
 
-  /* Parent and child have to share the quantum that the forked process had,
-   * so that queued processes do not have to wait longer because of the fork.
-   */
-
   /*
-   * we want to avoid having processes that loose their quantum without going
-   * through the standard path where the "out of quantum" is handled. We add
-   * some more time to such processes.
-   *
-   * This is a temporary solution until we are able to handle this in the
-   * userspace
+   * if the child process inherited a scheduler, the child process is not
+   * runnable until it's scheduled. Otherwise the default kernel policy applies.
+   * This is only the case of system servers, drivers and similar sensitive
+   * processes
    */
-  if (rpp->p_ticks_left < 2)
-	  rpp->p_ticks_left = 2;
-
-  rpc->p_ticks_left =  rpp->p_ticks_left / 2;
-  rpp->p_ticks_left =  rpp->p_ticks_left / 2;	
-
-  assert(rpc->p_ticks_left > 0 && rpp->p_ticks_left > 0);
+  if (rpc->p_scheduler)
+	  RTS_SET(rpc, RTS_NO_QUANTUM);
 
   /* If the parent is a privileged process, take away the privileges from the 
    * child process and inhibit it from running by setting the NO_PRIV flag.
diff --git a/servers/pm/main.c b/servers/pm/main.c
index 0751c62dc..2fdafbb93 100644
--- a/servers/pm/main.c
+++ b/servers/pm/main.c
@@ -504,7 +504,9 @@ PRIVATE void handle_fs_reply()
 	break;
 
   case PM_FORK_REPLY:
-	/* Wake up the newly created process */
+	/* Schedule the newly created process ... */
+	schedule_process(rmp);
+	/* ... and wake it up */
 	setreply(proc_n, OK);
 
 	/* Wake up the parent */