Messages in this thread | | | Date | Sun, 12 Sep 2004 21:34:12 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] Yielding processor resources during lock contention |
| |
* Zwane Mwaikambo <zwane@linuxpower.ca> wrote:
> > but unless the SMP case is guaranteed to work in a time-deterministic > > way i dont think this patch can be added :-( It's not just the question > > of high latencies, it's the question of fundamental correctness: with > > large enough caches there is no guarantee that a CPU will _ever_ flush a > > dirty cacheline to RAM. > > The suggested usage of monitor/mwait avoids that scenario, the recommended > usage being; > > while (*addr != condition) { > monitor(addr) > if (*addr != condition) > mwait(); > } > > This method is used because you can receive spurious wakeups from > mwait. Like 'hlt' an interrupt, NMI, SMI etc will cause the processor > to continue executing the next instruction after mwait. The extended > sleep state however could occur if interrupts are disabled which isn't > the case with the current users. So there is a sense of time > deterministic behaviour with an operating system which uses a periodic > timer tick for example. But regardless of that, i also think this > requires further clarification with respect to side effects and > benchmarking with current hardware.
right now we might have a periodic timer interrupt, but for the sake of powersaving (and for virtualization) we want to try variable rate timer interrupts real soon, which would remove any sort of determinism from the mwait() loop. So we cannot take this approach unless CPU makers guarantee the behavior. Right now it's inherently fragile.
Besides, even a 1msec upper cap on spinlock-wait times is totally unacceptable from a latency and quality of implementation point of view.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |