Date: Fri, 01 Feb 2002 04:18:09 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Luigi Rizzo <rizzo@icir.org> Cc: Alfred Perlstein <bright@mu.org>, Mike Silbersack <silby@silby.com>, Storms of Perfection <gary@outloud.org>, thierry@herbelot.com, replicator@ngs.ru, hackers@FreeBSD.ORG Subject: Re: Clock Granularity (kernel option HZ) Message-ID: <3C5A8781.3FFCA6B4@mindspring.com> References: <20020131172729.X38382-100000@patrocles.silby.com> <3C59E873.4E8A82B5@mindspring.com> <20020201002339.C48439@iguana.icir.org> <20020201002835.I18604@elvis.mu.org> <20020201004658.A48810@iguana.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > but exactly because of this reason, the overhead of netisr should > be less and less relevant as the processing increases. Not really. You are barriered up and down, and in any request/response, you won't be able to process both in the same NETISR, it will take (at least) 2 NETISR to do the work; likely 5 (see my example 1K static page server for HTTP). > Unless of course you end up in livelock, in which case performance > drops to 0 without processing-to-completion, and then the performance > improvement is arbitrarily high (see the table in > http://info.iet.unipi.it~luigi/polling/ ). 8-). I haven't really had a chance to comment on this; rather than going off on it without a detailed lab study with my own results, let me say that IP forwarding is cheating, since you have another livelock at the interface between user space and system space. The fix only works for the IP forwarding. This is basically the method that Mogul suggests in his 1993 paper. Mohit Aron's group at Rice University also discused using Weighted Fair Share Scheduling. There are a number of good reasons to not like this approach, even given the very smart people it came from, and the idea of fumbling in the scheduler code to decide on interrupts for kernel vs. user space time, really irks me. It makes too many assumptions about how much overhead my processing is going to take, and the distribution of the processing around the mean/median costs. One approach you might try to handle this -- and to know "when to switch", which you noted was "hard" -- would be to add an elements-on-queue counter to the queues involved (this should be an option in any case; my own macros for this are identical to the current queueuing macros, with a "C" on the front of them; counted queues are useful for doing RED-queueing, as well). If the count goes over a certain depth, then you want to disable interrupts entirely, so that the user space application gets a chance to run, and drains out the queue. For the NETISR processing (polling), you would use comparative queue depth to know "when to turn it on". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C5A8781.3FFCA6B4>