CS372H Spring 2010 Homework 1 Solutions

        1. What is the effect of having such a large number of registers on the operating system?
        2. What additional hardware features you would recommend added to the design above.
        3. What happens if the hardware designer also wants to add a 16-station pipeline into the CPU. How would that affect the context
            switching overhead?

1. The cost of a context switch or interrupt handling becomes very expensive. Also, the data structures that store the registers as part of a process context become large. This leads high overhead in memory and also may make the implementation of lightweight threads expensive.
2. A multithreaded architecture would be a good use of the abundance of registers. The idea is to partition the registers into a number of banks, for example, a set of 1024 registers could be divided into 32 banks of 32 registers each. Then, wewould be able to have the register sets of 32 processes without having to save it or restore it each time a context switchoccurs.
3. Since the pipeline has to be flushed on an interrupt, a deeper pipeline will take time to be flushed, increasing the latency of serving the interrupt and overhead. The penalty of a context switch increases.

main(int argc, char ** argv)
{
int child = fork();
int c = 5;

if(child == 0)
{

c += 5;
}
else
{
child = fork();
c += 10;
if(child)
c += 5;
}
}
 

main(int argc, char ** argv)
{
forkthem(5)
}
void forkthem(int n)
{
if(n > 0)
{
fork();
forkthem(n-1);
}
}

Program 1:
main()
{
    val = 5;
    if(fork())
        wait(&val);
    val++;
    printf("%d\n", val);
    return val;
}

Program 2:
main()
{
    val = 5;
    if(fork())
        wait(&val);
    else
        exit(val);
    val++;
    printf("%d\n", val);
    return val;
}
 

In the first program, the parent process creates a child and then waits for the child to exit (through the system call "wait"). The child executes and prints out the value of val, which is "6" after the v++ statement. The child then returns the value of val to the parent, which receives it in the argument to "wait" (& val). The parent then prints out the value of val, which is now 7. Note that the parent and child have seperate copies of the variable "val".

Using similar reasoning, you can see that the parent in program 2 waits for the child to return, and the child exits immediately. In this case only one value gets printed out which is the number 6 (from the parent process).

A typical hardware architecture provides an instruction called return from interrupt, and abbreviated by something like iret. This instruction switches the mode of operation from supervisor mode to user mode. This instruction is usually only available while the machine is running in supervisor mode.

    1. Explain where in the operating system this instruction would be used.
    2. What happens if an application program executes this instruction?

1. The operating system calls "iret" whenever it wants to give control to a user program. This happens at the end of a contextswitch, or when an interrupt service routine is finished.
2. Since the "iret" instruction is usually a privileged instruction, an application program trying to execute it will cause a hardware exception, because it is illegal for user programs to execute privileged opcodes.

• Run your experiment on two different hardware architectures and report the results.
• Explain the difference (if any) between the time required by your simple procedure call and simple system call by discussing what work each call must do (be specific). [Note: Do not provide the source code for your program, just the results].

Hint: You should use system calls such as gethrtime() or gettimeofday() for time measurements. Design your code such that the measurement overhead is negligible. Also, be aware that timer values in some systems have limited resolution (e.g., millisecond resolution).

A system call is expected to be significantly more expensive than a procedure call (provided that both perform very little actual computation). A system call involves the following actions, which do not occur during a simple procedure call, and thus entails a high overhead:

• A context switch
• A trap to a specific location in the interrupt vector
• Control passes to a service routine, which runs in 'monitor' mode
• The monitor determines what system call has occurred
• Monitor verifies that the parameters passed are correct and legal

#include <sys/time.h>
#include <unistd.h>
#include <assert.h>

int foo(){
  return(10);
}

long nanosec(struct timeval t){ /* Calculate nanoseconds in a timeval structure */
  return((t.tv_sec*1000000+t.tv_usec)*1000);
}

main(){
  int i,j,res;
  long N_iterations=1000000; /* A million iterations */
  float avgTimeSysCall, avgTimeFuncCall;
  struct timeval t1, t2;

  /* Find average time for System call */
  res=gettimeofday(&t1,NULL); assert(res==0);
  for (i=0;i<N_iterations; i++){
    j=getpid();
  }
  res=gettimeofday(&t2,NULL);   assert(res==0);
  avgTimeSysCall = (nanosec(t2) - nanosec(t1))/(N_iterations*1.0);

  /* Find average time for Function call */
  res=gettimeofday(&t1,NULL);  assert(res==0);
  for (i=0;i<N_iterations; i++){
    j=foo();
  }
  res=gettimeofday(&t2,NULL);   assert(res==0);
  avgTimeFuncCall = (nanosec(t2) - nanosec(t1))/(N_iterations*1.0);
 

  printf("Average time for System call getpid : %f\n",avgTimeSysCall);
  printf("Average time for Function call : %f\n",avgTimeFuncCall);
}

Sample output on a linux machine :

> gcc -O0 testtime.c -o testtime
> ./testtime
Average time for System call getpid : 394.778015
Average time for Function call : 15.080000