setaside funcs

[Cliff Woolley <cl...@yahoo.com>]

So Brian's message on dev@httpd prompted me to go take a peek back into
those issues with mmap_setaside() doing naughty things.  The thread
discussing it ended with here:

<Pi...@cobra.cs.Virginia.EDU>

Can you guys go back and reread that thread and then comment on the
options I presented in the above message?  That'd be great.

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA

Re: setaside funcs

[Aaron Bannert <aa...@clove.org>]

On Sat, Sep 29, 2001 at 06:20:15PM -0400, Cliff Woolley wrote:
> On Sat, 29 Sep 2001, Justin Erenkrantz wrote:
> 
> > +1 on option 1 (reopening and re-mmaping only when necessary).  It's
> > performance would *have* to be better than doing a silly memcpy.
> 
> It occurs to me that there could be a bit of a snag here that we'll have
> to work around, which is this: when file_read() mmaps the file, it mmaps
> it starting at the current bucket offset.  That makes sense, because if
> our file bucket only represents the last 100 bytes of a 10MB file, there's
> no sense in MMAPing the whole 10MB.  The only trick is that when you go
> BACK to representing it as a file, you have to figure out what the
> original offset into the file was and what the current mmap bucket offset
> is and add those together to get the absolute offset into the file.  And I
> don't think we currently store the original offset.  Oh well, just one
> more thing to store, I guess....

What's wrong with just mapping the whole file? It'll only page in the parts
that you access, right? There should be no fear of running out of memory,
since it only takes from memory+swap what you have paged in, and the rest
is considered "file-backed" by the actual file. Just a thought... not that
it helps in this case. :)

-aaron

Re: setaside funcs

[Cliff Woolley <cl...@yahoo.com>]

On Sat, 29 Sep 2001, Justin Erenkrantz wrote:

> +1 on option 1 (reopening and re-mmaping only when necessary).  It's
> performance would *have* to be better than doing a silly memcpy.

It occurs to me that there could be a bit of a snag here that we'll have
to work around, which is this: when file_read() mmaps the file, it mmaps
it starting at the current bucket offset.  That makes sense, because if
our file bucket only represents the last 100 bytes of a 10MB file, there's
no sense in MMAPing the whole 10MB.  The only trick is that when you go
BACK to representing it as a file, you have to figure out what the
original offset into the file was and what the current mmap bucket offset
is and add those together to get the absolute offset into the file.  And I
don't think we currently store the original offset.  Oh well, just one
more thing to store, I guess....

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA

Re: setaside funcs

[Justin Erenkrantz <je...@ebuilt.com>]

On Fri, Sep 28, 2001 at 11:19:47PM -0400, Cliff Woolley wrote:
> 
> So Brian's message on dev@httpd prompted me to go take a peek back into
> those issues with mmap_setaside() doing naughty things.  The thread
> discussing it ended with here:
> 
> <Pi...@cobra.cs.Virginia.EDU>
> 
> Can you guys go back and reread that thread and then comment on the
> options I presented in the above message?  That'd be great.

+1 on option 1 (reopening and re-mmaping only when necessary).  It's 
performance would *have* to be better than doing a silly memcpy.

I don't like saying we can't setaside on disjoint pools and I
think we should keep this with the pool cleanup code in case the
bucket isn't destroyed properly (is that possible?).  -- justin

P.S. Thanks to Cliff's reference to a msgid and my continued
annoyance at grepping through the archives manually, 
www.apachelabs.org now has a quicky Message-ID search feature
that tells you where the message id came from.  Look at the bottom.