Date: Fri, 30 Nov 2001 18:37:33 +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: <20011130174232.R347-100000@gamplex.bde.org> In-Reply-To: <20011129063116.B19430@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
> right now) because the purpose is to sample what the CPU is doing
> when we get that particular interrupt.
Why in that particular interrupt? If you do it in a timeout routine,
then you will normally do it in sync with hardclock interrupts
but delayed by some fraction of a hardclock interrupt. I think the
fraction can be compensated for if necessary. Doing it in sync with
statclock interrupts might be slightly better, but statclock interrupts
are _supposed_ to be non-periodic (FreeBSD just doesn't implement this),
so adjustments for fair sampling are strictly required.
In -current, hardclock() and softclock() are called in fast interrupt
context, so adding to them is both nontrivial and BAD (it requires
aquiring sched_lock because all write accesses and certain read accesses
to variables accessed by the fast interrupt handler, and this is still
not done for at least all of the ntptime variables).
> 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?
> Certainly I do not want it to be run after other netisr handlers
> (this is also why NETISR_POLL is lower than any other NETISR, so
> the corresponding handler is called first).
> It looked like the schednetisr() was the simplest (one-line change) and
> more effective way to achieve this, if you know of other ways involving
> timeouts please let me know.
schedsoftnet() doesn't quite work, but you could add another interrupt
class (`poll' instead of `net') in RELENG_4. This takes about 1 line
of changes in each of 6 files. All hardware interrupts would have
higher priority (sort of), but it is easy to make the new priority
higher than all SWI priorities. SWIs are easier to add in -current,
but have much higher overheads (which is not a problem for polling
every 100 seconds but very bad for much higher rates).
> Re. the first one, yes the code might probably benefit from
> a bit of rearrangement, such as below
>
> #ifdef XORP_ETHER_POLLING
> call _idle_poll
> #else
> call _vm_page_zero_idle
> #endif
> testl %eax, %eax
> jnz idle_loop
>
> with idle_poll being
>
> int idle_poll() {
> {
> idle_done=1;
> if (poll_handlers > 0) {
> int s = splimp();
> __asm __volatile("sti" : : : "memory");
Ugh. Use a standard FreeBSD C interface for this (critical_exit() in
-current; enable_intr() for i386's only in RELENG_4).
> retval = ether_poll(poll_burst);
> __asm __volatile("cli" : : : "memory");
> splx(s);
> vm_page_zero_idle();
> return 1;
> } else
> return vm_page_zero_idle();
> }
It's ugly for idle_poll() to know about all the other poll routines
(we've had other there before, e.g., one for apm).
> The thing is, with polling you cannot halt the CPU if there are handlers
> registered for polling. You can try and deregister polling on
> interfaces which are idle, which then should be handled correctly
> by the above function.
Yes, it's hard to reach hlt if there are any active interfaces. Maybe
limit the polling and switch to interrupt mode to wake up from hlt.
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?20011130174232.R347-100000>