[ipxe-devel] undi ipxe taking 100% cpu under vmware when boot server is offline
lustu.starrysky.cru at gmail.com
lustu.starrysky.cru at gmail.com
Wed Oct 19 19:42:30 UTC 2011
excuse me if I say something silly, as I am no expert in this matter...
wouldn't it be _much_ easier to use a greater demultiplier for the timer
interrupt, such that it will trigger more often than the default 18.2 Hz
frequency?
thanks!
starrysky
On Wed, Oct 19, 2011 at 07:12, Michael Brown <mbrown at fensystems.co.uk>wrote:
> On Tuesday 18 Oct 2011 21:30:58 lustu.starrysky.cru at gmail.com wrote:
> > I am running ipxe with UNDI driver under VmWare (don't know if the
> > driver matters at all).
> >
> > I consistently see it taking 100% cpu under even when boot server is
> > offline.
> >
> > Searching through the source code I see that cpu_nap() is being used
> > exactly for making sure ipxe doesn't take 100% of the guest cpu while
> > waiting, which would be too much of the host cpu.
> >
> > Is there any place where ipxe is still doing busy waiting?
>
> At present, iPXE will only call cpu_nap() when it knows that it is idle,
> such
> as when waiting for command line input. The reason for this is that
> cpu_nap()
> imposes a delay of up to 1/18s (one timer tick) before the next incoming
> network packet will be processed, since iPXE doesn't enable interrupts on
> the
> network card.
>
> The upshot of this is that if iPXE is non-idle (e.g. waiting for a DHCP
> response) then it will use 100% CPU.
>
> A proper solution to this would probably involve adding an activity counter
> (similar in principle to the device usage counter device_keep_count) which
> is
> incremented for each open TCP connection or other object that might rely
> upon
> timely receipt of network traffic. A "sleep" process could then call
> cpu_nap()
> only when the activity counter is at zero.
>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20111019/2295d583/attachment.htm>
More information about the ipxe-devel
mailing list