Preempt & how long it takes to interrupt (was Re: [2.4.17/18pre] VM and swap - it's really unusable)

Pavel Machek
2002-01-20T19:01:39Z

Hi!

> > I preempt leads to disaster than Linux can't do SMP. Are you saying that's
> > the case?
>
> There is a difference. Preempt have the same locking requirements as
> SMP, but there's also _timing_ requirements.
...
> > The preempt patch is really "SMP on UP". If pre-empt shows up a problem,
> > then it's a problem SMP users will see too. If we can't take advantage of
> > the existing SMP locking infrastructure to improve latency and interactive
> > feel on UP machines, than SMP for linux DOES NOT WORK.
>
> One example where preempt may break and SMP does not:
>
> Consider driver code. Critical data structures is protected by
> spinlocks,
> but some of the access to the hardware device itself is outside those
> locks (I can prove that the other processors can't get there with
> the driver in that state anyway)
>
> Now, hardware access has timing requirements. That works on SMP because
> you don't loose the CPU to anything but interrupts, and they are fast.
> You get it back almost immediately. The device in question times out
> after a much longer interval.

So... how long do you have to stay in interrupt for it to be a bug?

There's *no* requirement that says "it may not take second to handle
an interrupt". Actually I guess that some nasty conditions (UHCI needs
reset?) may take that long in interrupt. Oh and actually few releases
ago, console switching was done from interrupt and it *did* take 2
seconds for me.

If someone assumes interrupts are "short", he has broken code already.

Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa