httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: OSDI paper - IO-Lite: A Unified I/O Buffering and Caching System
Date Thu, 04 Mar 1999 09:17:07 GMT
On Wed, 3 Mar 1999 bhyde@pobox.com wrote:

> 
> To give a very quick overview of this paper it is an I/O model
> based on what I might call the "I will never copy data" design
> pattern.  This is analagous to the sweet spot that Dean likes to
> point out where with perfect hardware, a perfect OS and carefully
> crafted code when you mmap the file and send it the bytes can
> avoid ever even entering the CPU or it's backside cache.

humming at wire speed, yeah! 

> They manage data in buffers that are lists of pairs
> <pointer,length> and sets of buffers reside in memory spaces with
> compatible ACL (access control list) settings.  Care is taken to
> get the data to flow from file system caches to I/O devices never
> never never ever coping the data.  Reference counts get involved
> to allow caching to work.  They are very fastidious that the
> buffers are write once, but I could not see how they manage the
> interaction with paging to enforce that and if they do how that
> actually works out in practice.

When you transfer a buffer across a protection boundary it's write
protected I think.  That kind of hurts, costs a TLB flush... oops I
claimed it wasn't so on linux-kernel, mustn't have been awake. 

> For example if you used this with Apache and three dozen backend
> modules the back end modules would write into buffers their HTTP
> responses and then pass those off to Apache in shared memory that
> presumably Apache would have only read only access to.  That
> doesn't look practical given the finite number of memory mapping
> registers most machines have.  Everybody knows that if you own
> the paging registers you rule the world.

Dude, paging registers?  memory mgmt has progressed a little beyond that
now ;)  We have two or three level page tables these days, you can futz
with memory at 4k or 8k boundaries. 

> I found thought provoking the term "early multiplexing" i.e. if
> you are to never copy the data you have to be sure that the
> incomming packets fall directly into the buffer space with the
> approprate ACL to cover all the down stream usage.

I'm still trying to figure out how this magic works.

> This is identical to the problem Apache has with wanting to get
> the incomming request into the process space and threading model
> of the module or back end process that actually is going to deal
> with it.

bingo. 

Dean


Mime
View raw message