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: Marcus Brinkmann
Subject: Re: I/O permission control in OSKit-Mach
Date: Tue, 16 Oct 2001 12:09:07 +0200
User-agent: Mutt/1.3.22i

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).

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?

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de



reply via email to

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