[RFC] remove bus_memio.h and bus_pio.h

Scott Long scottl at samsco.org
Mon May 30 10:57:30 PDT 2005


M. Warner Losh wrote:
> In message: <4299FD87.1000505 at samsco.org>
>             Scott Long <scottl at samsco.org> writes:
> : This kind of makes me sad.  I don't see how this was harming anything,
> : it just wasn't documented so people didn't know how to use it.  If it
> : didn't apply to non-i386 and amd64, fine, just don't implement it for
> : those platform.  This optimization might have seemed trivial, but it's
> : all of the little trivial optimizations that add up to make a nice
> : system.  I'm guessing that Justin only put effort into this originally
> : because he did see a benefit; discounting it without doing any testing
> : of your own is a bit disingenuous.
> 
> I've been unable to measure any difference in any of timing solution's
> drivers between having the bus_pio.h include and not having it at all
> (which disables the optimization).  This is on a 266MHz Pentium.  I'm
> guessing that the drivers did inb/outb/etc so infrequently that any
> benefit was swamped by the actual I/O.  Even at the maximum data rates
> that we could see (which did about 20k inb/outb a second) I couldn't
> measure any CPU difference, nor could I measure any performance
> difference.  I did this in the 4.3 time frame in our tree when looking
> to optimize a driver that was giving us trouble.  A back of the
> envelope calculation suggests that I should have seen about 100us/s of
> extra CPU time.  Since I ran the tests for about 1000 seconds, I
> should have seen .1s extra in CPU.  Maybe I did, but iirc the standard
> deviation of the measurements as much more than that.  I'll see if I
> can find the data I gathered at the time.
> 
> I've not measured anything with memio to see if that matters, or if
> there is anything different about newer pentiums and the branching
> effects.  However, when Justin introduced them in the 3.0 time frame,
> which is 1998.  According to Intel's web site, the Pentium II had just
> been introduced, which puts the CPU speeds at just a little faster
> than the embedded systems we run at work.  I also recall discussions
> with Justin at the time that said the biggest win was for 386 and 486
> machines, but I might be misremembering those discussions, since they
> were over lunch about 7 years ago.
> 
> Warner

Thanks for the explaination.  One thing to note is that the Soekris is
still a very popular platform, so this optimization might still be very
relevant there.  Even so, it was basically free, and the only thing it
lacked was documentation so that people could use it correctly.  It's
a shame that it's gone.

Scott


More information about the freebsd-arch mailing list