Date: Tue, 4 Nov 2003 23:08:38 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Vivek Pai <vivek@CS.Princeton.EDU> Cc: Alan Cox <alc@cs.rice.edu> Subject: Re: Update: Debox sendfile modifications Message-ID: <20031104221455.I9997@odysseus.silby.com> In-Reply-To: <3FA7EF77.5010808@cs.princeton.edu> References: <1066789354.21430.39.camel@boxster.onthenet.com.au> <20031022082953.GA69506@rot13.obsecurity.org> <1066816287.25609.34.camel@boxster.onthenet.com.au> <20031022095754.GA70026@rot13.obsecurity.org> <xzpk76sc425.fsf@dwp.des.no> <1067183332.3f9bece4c0cf4@webmail.cs.princeton.edu> <3FA2C43E.3030204@cs.princeton.edu> <3FA7EF77.5010808@cs.princeton.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031104221455.I9997>