Re: mmap() versus read()

Perry Harrington (pedward@sun4.apsoft.com)
Mon, 9 Mar 1998 18:27:44 -0800 (PST)

> >
> > [The function is not quite lightweight, but it could be improved: eg. the
> > clearing of the IO bitmap could be delayed until the first ioperm() call
> > by setting p->tss.bitmap outside of the TSS segment]
>
> And if it used LWPs, the ioperm would exist soley for the process container.
> Anything that isn't context related would be in the process container. It
> would seem that the overhead is due to the design, not the call. For all
> intents and purposes, LWPs could be implemented transparent to the clone()
> call, simply changing the semantics of creation and such. The threads
> could be scheduled in process groups (didn't someone add QNX process groups
> to 2.1?), each process group being isolated to a single process.
>

I realized the naivity of this remark shortly after I made it. There exists
a problem with the current implementation of clone, and a logical problem.
Firstly, if you create a thread with clone() it will not inherit the ioperms
of the parent, because it is zeroed out. Would it be possible to map the
io_bitmap of the parent into the chunk of memory that we need io_bitmap for?

You know, map a VM page over that? The other choice is to just do a bulk
copy of the parent's io_bitmap (fixing clone()) in the process. You could
take advantage of any highspeed bulk copies. The alternative is to grab
a page of memory that was previously zeroed out (can't the x86 do this in
hardware?) and just assume it's initialized.

--Perry

> >
> > i've attached the code that does the clone() latency measurement.
> >
> > -- mingo
> > 

-- 
Perry Harrington       Linux rules all OSes.    APSoft      ()
email: perry@apsoft.com 			Think Blue. /\


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu