![]() | |||||||||||
Messages in this thread |
On 01-01-08 20:35, Christer Weinigel wrote: > On Tue, 1 Jan 2008 19:46:59 +0100 > Ingo Molnar <mingo@elte.hu> wrote: > >> * Christer Weinigel <christer@weinigel.se> wrote: >> >>> What I'm afraid is that udelay will be significantly slower, [...] >> why should it be significantly slower? > > out 80h, al is only two bytes. Any alternative that has been suggested > in this discussion will use more space. mov dx, alt_port; out dx, al > will be larger, a function call will definitely be a lot larger. People > have been making changes to the kernel to save a couple of hundred > bytes of text size. > > On old hardware (or anything with an ISA bus which I'd guess includes > the Geode SCx200 SoC which is basically a MediaGX processor, a > southbridge and an ISA bus with a Super I/O chip on it) an out to 80h > will use exactly one ISA cycle. Not to disagree with the point but more like 8 (1 us at 8 MHz). It's the timeout property. > A call to udelay will need a margin, > so it will be slightly slower. And that's assuming that you can find > out the speed of the ISA bus, if you can't you'll have to assume the > slowest possible bus (6 MHz I guess) which will be a lot slower. > > I don't know if the difference in code size or the udelay will be > significantly slower, but I think it might be. There's also the bit about microseconds being very losely defined pre loops_per_jiffy calibration. Per CPU-family init helps somewhat but certainly for family 6 (Pentium Pro, II, III -- lots of hardware with ISA busses therefore) speeds vary quite a bit still. > And to take the MediaGX as an example, the TSC is not usable on that > CPU, so Linux has to use the PIT timer for gettimeofday. As I wrote > in a different post, I believe the PIT on the SCx200 needs outb_p to > work reliably. So if outb_p becomes significantly slower that will > affect a critical path on a very common embedded CPU. > > I'm not sure what Alan meant with his comments about locking, but if > changing outb_p to use an udelay means that we have to add locking, > that is also going to affect the code size and speed. Explained here: http://lkml.org/lkml/2007/12/30/136 However, that's not an argument. Missing locking is a bug, and current outb I/O delay use hiding it doesn't change that. Rene. | ||||||||||
| Last update: 2008-01-01 21:05 [from the cache] ©2003-2008 | |||||||||||