On Fri, Aug 26, 2005 at 01:23:15AM -0700, Brian Pane wrote: > > On Aug 26, 2005, at 12:55 AM, Joe Orton wrote: > > >On Fri, Aug 26, 2005 at 12:42:19AM -0700, Brian Pane wrote: > > > >>The attached patch delays the setting of TCP_NODELAY on client > >>connections until the first time core_output_filter has to do a > >>writev_it_all() or emulate_sendfile(). My motivation for this is to > >>work around the TCP_NODELAY/TCP_CORK problem in Linux 2.6. However, > >>it also will save a couple of syscalls for any request that is > >>handled > >>with sendfile(2). > >> > > > >This will actually end up being *more* expensive on 2.6 systems in the > >long run, though, right? I'm not convinced this is a good idea. With > >APR changed to allow setting TCP_CORK and TCP_NODELAY at the same time > >with 2.6, it is cheaper to just set TCP_NODELAY once on the listening > >socket and never have to touch it again. > > I didn't think it was actually possible for APR to allow TCP_CORK and > TCP_NODELAY > at the same time. From the tcp(7) manual page on my FC4 installation,
That's out of date yes, see recent thread ;) All 2.6.x kernels do allow setting both TCP_CORK and TCP_NODELAY at the same time. All current 2.6.x kernels have the bug in TCP_CORK handling which means that if TCP_NODELAY was ever enabled on the socket, TCP_CORK will not take effect. The fix for that was in the 2.6.13-rc7 release, for the curious: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=89ebd197eb2cd31d6187db344d5117064e19fdde ... > If it's possible to use both TCP_CORK and TCP_NODELAY on the same > socket in 2.6.13 or later (assuming that's when the fix for the current > NODELAY toggling problem becomes available), then yes, my lazy > evaluation approach will be less efficient than just setting TCP_NODELAY > on the listener socket--for requests that don't use sendfile. > For requests that do use sendfile, I think the logic implemented by my > patch will be optimal for both 2.6.1-2.6.12 and 2.6.13+ To be clear this is only a partial workaround for the kernel bug: if at any time something is sent on the connection which requires enabling TCP_NODELAY, any subsequent TCP_CORKs will have no effect. Given that fact I'm not convinced it's worth changing httpd: this is (1) a kernel bug and (2) an APR lack-of-feature; with both of those things fixed the current httpd code is perfectly correct. joe
