Update: Debox sendfile modifications

Mike Silbersack silby at silby.com
Tue Nov 4 21:08:46 PST 2003

On Tue, 4 Nov 2003, Vivek Pai wrote:

> The one other aspect of this is that sf_bufs mappings are maintained for
> a configurable amount of time, reducing the number of TLB ops. You can
> specify the parameter for how long, ranging from -1 (no coalescing at
> all), 0 (coalesce, but free immediately after last holder release), to
> any other time. Obviously, any value above 0 will increase the amount of
> wired memory at any given point in time, but it's configurable.

Ah, I missed that point.  Did your testing show the caching part of the
functionality to be significant?

> There are two problems to this approach that I see
> a) you'd have to return a value back to sendfile while this async
>     operation is in progress, because you don't have any other
>     non-intrusive way of giving back the return value at any other time
> b) once that small number of kernel threads gets exhausted, you lose
>     the opportunity to serve requests out of main memory
> part (a) means that this change can't be made completely without
> application re-coding, and part (b) means that more sophisticated
> applications could lose performance.
> How about something that lets you choose what happens - we've got a
> flag field anyway, so why not have options to control the behavior on
> missing pages? Applications like Flash might just want the error
> message so that they can handle it themselves, while other applications
> may be happy with the default that you're suggesting.
> -Vivek

Yeah, I guess you're right; as John-Mark Gurney also pointed out, it would
be extremely difficult to hide the asychronous implementation.  Assuming
that we came up with an extra flag which told sendfile to use asynchronous
mode (and raised the maximum number of such threads), wouldn't it be even
more efficient than Flash's helper threads?

Mike "Silby" Silbersack

More information about the freebsd-hackers mailing list