Old server: two Xeon E5450 chips, 3.0 GHz, 8 cores total, 24 GB RAM.

New server: one Xeon E5-2690 chip, 2.9 GHz, 8 cores total, 32 GB RAM.

Wow, nice, that was exactly the HW I was predicting; the fastest single-core-performance xeon under turboboost.

Test comment.

It's unborked.

Test reply.

xxxxx

Address spaces based on paging rather than segments. Much clearer context switching code. File system crash recovery via logging.

And now using the HLT instruction so you don't chew CPU power unnecessarily, great for QEMU etc on laptops. I just sent you a patch.

Edit: all the user tests passed.

One thing I forgot to mention, now that the scheduler code has been changed the famous "you are not expected to understand this" comment is gone.

Most students take 6.828 along with three or four other courses.

xxx

Test 1.

Test 2.

Testing.

fork() and exec() work well as separate system calls for the common situation where the child (but not the parent) needs to adjust something before executing the new program. Changing file descriptors to implement > and < in the shell, for example. It's common to see sequences like

  pid = fork();
  if(pid == 0){
    close(1);
    dup(pipefds[1]);
    exec(...);
  }

Aye. This way, we can control a large number of aspects of the child's environment in which execve() is called, without having to have execve() do all that work for us. We can open files, change the session id, reparent the process to init, alter environment variables, lower process limits, change credentials, change the root directory... the possibilities are legion.

You wouldn't want to have to design a way to pass all of those things to execve(), would you?