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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
