Hi, Alan Cox wrote: > So with pre-empt this happens > > driver magic > disable_irq(dev->irq) > PRE-EMPT: > [large periods of time running other code] > PRE-EMPT: > We get back and we've missed 300 packets, the serial port sharing > the IRQ has dropped our internet connection completely. But it shouldn't deadlock as Victor is suggesting. > There are numerous other examples in the kernel tree where the current code > knows that there is a small bounded time between two actions in kernel space > that do not have a sleep. They are not spin locked, and putting spin locks > everywhere will just trash performance. They are pure hardware interactions > so you can't automatically detect them. Why should spin locks trash perfomance, while an expensive disable_irq() doesn't? bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo _at_ vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Follow-Ups:
- Re: [2.4.17/18pre] VM and swap - it's really unusableAlan Cox <alan _at_ lxorguk.ukuu.org.uk>
- Re: [2.4.17/18pre] VM and swap - it's really unusableRob Landley <landley _at_ trommello.org>
- Re: [2.4.17/18pre] VM and swap - it's really unusableAlan Cox <alan _at_ lxorguk.ukuu.org.uk>
- Prev by Date: Re: Writeout in recent kernels/VMs poor compared to last -ac
- Next by Date: Re: Driver via ac97 sound problem (VT82C686B)
- Previous by thread: Re: [2.4.17/18pre] VM and swap - it's really unusable
- Next by thread: Re: [2.4.17/18pre] VM and swap - it's really unusable
- Indexes:[Main][Thread]