polling(4) and idle time/cpu usage percentages

[Don Bowman]

From: Luigi Rizzo [mailto:rizzo at icir.org]
> [Polling in SMP case]
> 
> Interesting! Well, let's see:
> 
> The polling code (including the code that schedules the cpu
> between kernel and userland) is written upon the assumption 
> that only one
> polling loop is active. Now, because polling can occur in the idle
> loop or right after hardclock, and there are multiple concurrent
> idle_loops in the SMP cases, and the locking is just not there.
> 
> Probably, the reason it works for you is that likely there is only
> one instance of hardclock handler, _and_ the idle_loop code is
> different for the UP and SMP cases, and I only provided polling
> hooks for the former. So you are limited to doing polling only in
> the assigned fraction of CPU, and the CPU(s) will not use any extra
> CPU for polling even if available.

I think since idle_poll does:
int
idle_poll(void)
{  
        if (poll_in_idle_loop && poll_handlers > 0) {
                int s = splimp();
                in_polling = 1;
                enable_intr();
                ether_poll(poll_each_burst);
                disable_intr();
                splx(s);
                vm_page_zero_idle();
                in_polling = 0;
                return 1;
        } else
                return vm_page_zero_idle();
}

that it won't matter since splimp() is held.

Am I missing something?  I should be able to place a call
to _idle_poll in the swtch.s idle_loop() for SMP?

not sure why it enables interrupts before calling poll,
and disables them afterwards?