Date: Wed, 27 Jun 2001 21:38:12 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: John Baldwin <jhb@FreeBSD.org>, Jonathan Lemon Alfred Perlstein <bright@sneakerz.org>, "Brian F. Feldman" <green@FreeBSD.org>, Mike Silbersack <silby@FreeBSD.org>, <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org>, <jlemon@FreeBSD.org>, <bmilekic@FreeBSD.org> Subject: Re: cvs commit: src/sys/netinet tcp_input.c tcp_output.c tcp_sub Message-ID: <Pine.BSF.4.33.0106272128380.96893-100000@herring.nlsystems.com> In-Reply-To: <200106271537.f5RFbIQ40573@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Jun 2001, Matt Dillon wrote: > > The BSDI code very specifically avoided the problem (gee, take one guess > why!) simply by ensuring that the interrupt thread preemption would be > equivalent from the coding point of view of a normal thread to a normal > interrupt in, say, 4.2. The normal thread would be guarenteed that > the interrupt thread preempting it would (A) not block from the stand point > of the normal thread (it gets scheduled instead and the normal thread > is resumed), and (B) would guarentee that the normal thread would > resume on completion. Not some other random thread, not on a different > cpu... the original thread would resume on the same cpu. This is why > BSDI implemented interrupt preemption as a special case, and while I > was not overly fond of it when it was discussed at the Yahoo meeting, it > was an order of magnitude *better* then what is in -current now! Matt, I think you are forgetting that on BSD/OS, when a lightweight ithread hits a held mutex, it then converts to a fully scheduled heavyweight thread, at which point any kind of preemption you can think of can happen. Since we don't have sufficient lock pushdown to get any significant part of the kernel outside the scope of Giant, any implementation of lightweight ithreads would not make a noticeable performance improvement because it will be contending on Giant too often. This same problem tends to double the number of context switches in our existing implementation which is a major performance issue. In the long run, we need to implement lightweight ithreads but until we can get a significant fraction of the kernel out from under Giant, performance is not going to improve. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.33.0106272128380.96893-100000>