Messages in this thread | | | Date | Thu, 20 Dec 2007 21:04:12 +0100 | From | Arjan van de Ven <> | Subject | Re: [PATCH] sky2: Use deferrable timer for watchdog |
| |
Parag Warudkar wrote: > On Dec 20, 2007 2:22 PM, Kok, Auke <auke-jan.h.kok@intel.com> wrote: >> ok, that's just bad and if there's no user-defineable limit to the deferral I >> definately don't like this change. >> >> Can I safely assume that any irq will cause all deferred timers to run? > > I think even other causes for wakeup like process related ones will > cause the CPU to go busy and run the timers. > This, coupled with the fact that no one is yet able to reach 0 wakeups > per second makes it pretty unlikely that deferrable timers will be > deferred indefinitely.
0.8 is easy on single core today. multicore just increases how idle you can be for a given core.
> >> If this is the case then for e1000 this patch is still OK since the watchdog needs >> to run (1) after a link up/down interrupt or (2) to update statistics. Those >> statistics won't increase if there is no traffic of course... >> > > I think it is reasonable for Network driver watchdogs to use a > deferrable timer - if the machine is 100% IDLE there is no one needing > the network to be up. If there is something running even on the other > CPU - that is going to cause an IPI, reschedule, TLB invalidation etc. > which will make it very likely in practice that each CPU will be > interrupted in reasonable amount of time.
this is not correct; many machines are idle waiting for network data. Think of webservers...
> > Of course there are theoretical cases where we could land into a > situation where a CPU in a multiprocessor machine is IDLE infinitely > and that causes the watchdog that happens to be bound to run on the > same CPU to not run. To take care of these unlikely cases I think the > timer mechanism should have a reasonable limit on how long a CPU can > go IDLE if there are deferrable timers.
how about something else instead: a timer mechanism that takes a range instead.. that at least has defined semantics; the deferrable semantics really are "indefinite". Lets keep at least the semantics clear and clean.
| |