Messages in this thread | | | Date | Tue, 7 Dec 1999 08:02:11 -0800 (PST) | From | (Jim Gettys) | Subject | Re: [patch] Re: setitimer lowlatency-2.2.13-A1 questions |
| |
> Sender: owner-linux-kernel@vger.rutgers.edu > From: Ingo Molnar <mingo@chiara.csoma.elte.hu> > Date: Tue, 7 Dec 1999 00:23:06 +0100 (CET) > To: Andrea Arcangeli <andrea@suse.de> > Cc: Manfred Spraul <manfreds@colorfullife.com>, > William Montgomery <william@opinicus.com>, > linux-kernel@vger.rutgers.edu > Subject: Re: [patch] Re: setitimer lowlatency-2.2.13-A1 questions > ----- > On Mon, 6 Dec 1999, Andrea Arcangeli wrote: > > > For the ret to userspace case it could decrease a bit the bh latency > > but it seems not a big issue, as right now a ret from syscall will act > > like while returning from an irq after the bottom half path. > > bh latency is important in some cases, and often we do not return to > userspace for millisecs (tens of millisecs in other cases). This might > even explain some of the TCP oddities. >
Yup... Not sure which TCP oddity you are talking about, but my experience is that user programs need timely execution to get best TCP performance.
If userspace doesn't get to run quickly enough, it is easy to trigger delayed acks by not getting data out of the operating system fast enough (at least with the BSD TCP implementation). This can cause really poor performance. We ran into this one in our HTTP/1.1 implementation, where, since we were doing much more work on a single TCP connection, we found it was essential to become very agressive in our user space code at getting data out of the socket buffers (or we'd end up with delayed acks). In HTTP/1.0 using multiple TCP connections this was rarely a problem, but became essential to get things to really fly using HTTP/1.1.
- Jim Gettys
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |