Re: A comment about changing kernels

[Espen Skoglund]

[Jonathan S Shapiro]
> What the graph says is that a VERY careful IPC implementation can
> obtain a factor of 10 advantage over badly built legacy
> kernels. Since that measurement, the factor of advantage has already
> been reduced substantially by the declining relative performance of
> SYSENTER/SYSEXIT, to the point where the real advantage now may be
> as low as a factor of four. You now propose to throw away a factor
> of two, and state that we should not care.

> But what this appears to ignore is the L4Linux numbers. What the
> L4Linux numbers (and also the EROS microbenchmark numbers) show is
> that the current L4 (and EROS) IPC times are only barely good
> enough. This, by the way, is also confirmed by the recent work at
> UNSW confirming the continuing importance of the small space
> optimization.

I'm not sure I understand which recent work you're referring to here,
or how it helps back your argumentation.  Also, citing small spaces
papers is not really appropriate since all that these papers basically
say is that architectures with virtually tagged caches really suck
when you have high address space switching overheads. 

> 3. I have noticed that many of the older L4 numbers published by
> Jochen were based on implementations that were not entirely
> correct. At that time, for example, the L4 kernel *restored* segment
> registers, but did not save them. This turns out to be a
> communication channel. If the EROS implementation had taken the same
> (incorrect) short cut, our numbers would have been noticeably faster
> than that particular implementation of L4.

Just to set the record straight.  I believe that your comments here
are absolutely off target because:

  a) His kernel supported small spaces.  There's no way to implement
     small spaces correctly without reloading segment registers.  In
     other words: your statement is completely wrong.

  b) It makes absoultely no sense be paranoid about restricting the
     communication channel resulting from reloading segment registers
     when doing an IPC between two partners (i.e., you already have
     the communication channel).  Avoiding such a communication
     channel is only an issue when some other type of context switch
     occurs (and this is not on the critical IPC path).

I know that you stated the same claims in your "Vulnerabilities..."
paper, and so these claims are now on record as being the "truth".

        eSk