Messages in this thread | | | Date | Mon, 13 Sep 1999 17:10:49 +0200 (CEST) | From | mingo@chiara ... | Subject | Re: Lockups - lost interrupt |
| |
On Mon, 13 Sep 1999 yodaiken@chelm.cs.nmt.edu wrote:
> > i'm not sure wether this will ever be accepted into the main kernel - > > __cli()/__sti()/etc. right now is heavily used and inlined (mostly via > > The price is paid only if you select RTL in config. > my idea is that system.h does
oh, ok. I thought you want to do this 'runtime', by patching a pretty normal kernel dynamically.
> Lmbench can't detect any performance loss -- remember that cli and sti > are not cheap instructions anyways.
they are ~7 cycles, but the real cost is the slight kernel bloat (== more cache footprint) caused by the inlined function call. Anyway, this is of course not a problem for an optional thing, i thought you are trying to do this runtime as well.
> > spinlocks) and it's a single instruction. Maybe building a table of 'cli, > > sti, popfl, pushfl' addresses into a special section can do the trick > > without interfering with the 'normal' kernel? A single-instruction 'int 3' > > could be patched into those places, or something like that. > > The "int" would cost too much in the rtl case. On
the int is basically a function call if you do it on ring 0, but yes it's more expensive than a normal function call.
> the other hand, I had thought of > of a section. Not sure what the advantage would be. With the structure, > the compiler generates > > movel N+irq_desc,%eax > call *%eax
if the int3 solution is implementable (it's a tough problem i think), the advantage would be a completely unaffected 'main kernel'. RTL could be switched on/off runtime. OTOH, people recompile kernels routinely anyway.
-- mingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |