Date: Sat, 1 Dec 2001 05:30:14 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Luigi Rizzo <rizzo@aciri.org> Cc: <net@FreeBSD.ORG> Subject: Re: Revised polling code for STABLE Message-ID: <20011201042322.O2240-100000@gamplex.bde.org> In-Reply-To: <20011130084421.A30672@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 30 Nov 2001, Luigi Rizzo wrote: > On Fri, Nov 30, 2001 at 06:37:33PM +1100, Bruce Evans wrote: > > On Thu, 29 Nov 2001, Luigi Rizzo wrote: > > > > > The call to update_poll_threshold() however needs to be done by > > > either hardclock() or statclock() (i am experimenting with that > ... > > Why in that particular interrupt? If you do it in a timeout routine, > > i'll try to explain. > > One of the goal of polling is to be able to adapt the fraction of > CPU dedicated to polling so that it matches some user-programmable > threshold -- and in any case, make sure that you are never using > 100% of the CPU doing polling because in this case you would have > livelock and a non-responsive system. But this doesn't require _very_ accurate syncing with the hardclock interrupt. It's similar to scheduling. The scheduler runs approximately every 5 seconds and uses its load average calculation to adapt the fraction (sort of) of the CPU dedicated (sort of) to each process. It just uses timeout(). Ian Dowse recently found that this sometimes gave too accurate syncing and added some jitter (+-0.5 sec -- too much, I think). For your polling, I think the only significant difference is that the polling should not get too far behind because there are real- time requirements. Timeout routines will only get behind if the system is so overloaded that it doesn't call softclock() for every hardclock(), and dropping packets by simply missing polling deadlines may be the best way to reduce the load. > Out of the infinitely many ways of doing this, i am experimenting with > a couple: > ... > + (what i want to test next). Use the profiling clock to sample > cpu state, and determine (over the long term) what fraction of > these samples finds the CPU busy in ether_poll(). If the fraction > is higher than a programmed threshold then reduce poll_burst, > otherwise increment it. > This might give a more fine-grained control, but only works > on a longer scale term, and still I should check > ... > For the second scheme i probably do not need to run ether_poll() > from hardclock. But as you notice there are issues on how fair the > sampling would be, which I haven't had the time to deal with yet. I would try putting the sampling in a timeout routine, and handle the real-time issues in hardclock(), but hope that they aren't important and and up not handling them. hardclock() would just check that the polling routines got called enough during the previous N hardclock interrupt periods (N small enough), and arrange for some polling to be done at a very high priority as soon as possible. > > In -current, hardclock() and softclock() are called in fast interrupt > > context, so adding to them is both nontrivial and BAD (it requires > > well the code i am adding is really short, look at the patch! > It boils down to reading one variable and updating poll_burst > accordingly. Sorry, I deleted the patch. Everything that writes the variable would need locking or something to give atomic accesses. I don't remember where it is written. > > > I do not know how/if I can replace the schednetisr() with an ordinary timeout: > > > i need the handler to be invoked as soon as possible after the > > > clock ticks, as the task it performs are as urgent as interrupt requests. > > > > As urgent as hardclock interrupts? > > I'd say yes: as urgent, but with a lower priority. > If there are packets to fetch from the cards, those are packets > for which there would be an interrupt pending in a traditional > system, so they would be processed after hardclock but before > pending soft interrupts. I would like to keep this prioritization > as much as possible. With polling from timeout routines, doubling HZ would reduce the average latency to below that for polling from hardclock() or soon after. I think you need to increase HZ anyway, so increasing it even more would be acceptable. But you want the _worst-case_ latency to be not much larger than 1/(original HZ). See above about different polling in hardclock to handle this and why handling it might not be necessary. > I have considered adding another interrupt class (as a matter of fact, > i even did that) with higher priority than other SWI, but i thought > it was overkill because splsoftnet(NETISR_POLL) still seems to be > the highest priority soft interrupt and the change is less intrusive. > Am I wrong on this ? A little. splsoftty() is higher. Also, polling might be useful for non-net drivers. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011201042322.O2240-100000>