bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I/O permission control in OSKit-Mach


From: Adam Olsen
Subject: Re: I/O permission control in OSKit-Mach
Date: Tue, 16 Oct 2001 11:06:53 +0000
User-agent: Mutt/1.3.20i

On Tue, Oct 16, 2001 at 12:09:07PM +0200, Marcus Brinkmann wrote:
> On Tue, Oct 16, 2001 at 05:48:02AM +0000, Adam Olsen wrote:
> > On Tue, Oct 16, 2001 at 04:16:42AM +0200, Marcus Brinkmann wrote:
> > > A task requesting some I/O permission will get a full blown 8192 bytes 
> > > large
> > > bitmap, which is copied in the processor TSS at every switch to the task.
> > > (Linux by default only uses a half bitmap, and provides a full one at
> > > request by calling a special function -- not ideal either, 
> > > interface-wise).
> > 
> > Given how expensive copying 8192 bytes is bound to be, wouldn't it be
> > cheaper to break the bitmap up into segments, and when switching only
> > set the necesary parts?  (either zero the old ones and load the new
> > ones, or zero the old ones not used in the new one and load the common
> > ones.)  This'd probably be worse for everything that uses over half a
> > bitmap, but I have a feeling most usages will only be a small
> > fraction.
> 
> This idea is good, although managing the segments will be more
> complicated.  OTOH, in the usual case, you are only touching one segment once
> and stick with that.  What about this:  Along with the bitmap store a
> segment map in the task, which is an uint32_t.  This map starts out with 0,
> and when a task modifies its I/O bitmap, the segments (each 256 bytes long)
> that were modified are marked with 1 in the bitmap if you enable them.  If
> you disable I/O ports, nothing happens (so, if you enable all ports and then
> disable most of them, you loose).  (This matches what we do now if you have
> no I/O permission at all anymore, you still hang around with the bitmap. 
> Maybe splitting it up in segments makes it worth to change this also).

I was actually thinking of a list of segments, but that sounds way
better.  Basically a multilevel bitmap.

> 
> When you task switch, the segment bit maps are OR'ed, and only those segments
> are copied.  The actual number of segments (and thus their length) can be
> tuned, 128, 256, 512 and 1024 are convenient values.  Anybody has an idea
> what a good value on todays processors would be?

And of course AND NOT them to find the segments to clear.  I can't
think of any reason that we'd want segments larger than the smallest
value we can manage.  In fact, it may be beneficial to add another
layer, and split the 256 byte segments into 8 byte subsegments.  That
may be overkill though.  Any idea what the real costs involved are?

-- 
Adam Olsen, aka Rhamphoryncus



reply via email to

[Prev in Thread] Current Thread [Next in Thread]