Re: [RFC] remove bus_memio.h and bus_pio.h

From: Scott Long <scottl_at_samsco.org>
Date: Sun, 29 May 2005 11:36:07 -0600
M. Warner Losh wrote:

> In message: <20050525.212009.71136852.nyan_at_jp.FreeBSD.org>
>             Takahashi Yoshihiro <nyan_at_jp.FreeBSD.org> writes:
> : The bus_memio.h and bus_pio.h for a micro-optimization depend on the
> : implementation of the bus_space on i386 and amd64, so they are
> : meaningless files on the other archs.  I'd like to remove a MD part
> : like this from MI drivers at least.
> : 
> : I think that a increasing performance by using this method is very
> : trivial on recent machines.  If there is not strong objection, I'll
> : remove bus_{mem,p}io.h and related code from all archs.
> : 
> : Comments?
> 
> Short answer:
> 
> 	Great idea.  aac and bfe should be tested after the change to
> 	see if there is any benefit for them.  Other drivers almost
> 	certainly will see no benefit from this.
> 
> Longer, more detailed answer.
> 
> The original idea was to provide a hint to busspace that this driver
> only ever used a certain subset of the available mappings so it should
> assume that subset and agressively optimize the code.  The assumption
> was that one could know at compile time that one would never use
> certain features.  In an i386 centric world, this made good sense,
> especially since the bus_space_* macros expanded to inb or whatever
> and nothing else (compiler technology innovations may have changed
> this over time).
> 
> You are correct in that other architectures might have more than two
> kinds of address space, might have other complicating factors.  pc98
> has, as you know, an indirect vector because devices on the
> motherboard and cbus are rarely mapped at contiguous locations due to
> the dual 8-bit bus nature of the internal buses.  In that case it
> makes no sense to do any optimization at all, and these files should
> be empty for such an implementation.
> 
> Alpha, sparc64, powerpc and arm all have much more complex bus space
> implementations due to their greater intra-architectural differences,
> as well as their large difference with i386.  To similarly optimize
> these architectures, one would need additional MD info to know how to
> inline things.  None of them have chosen to support this level of
> optimization.  It is unclear to me how big a win such optimiztion
> would be, even on the slower CPUs some of these platforms support.
> 
> The lowest end of FreeBSD/i386 these days[*] is likely a Pentium II
> running at 300MHz or a soekris box.  The 4510 box is still only
> 166MHz.  However, the only device that it has that are likely to
> benefit from this is sio.  Well, in extreme cases, one could make the
> case for any pci card or pccard, but I think that's too extreme to
> consider.  Since the soekris box has only one free serial port, we
> need only keep up with a ppp connection on that serial port, so I'm
> pretty sure we're OK.
> 
> A number of drivers include only one of these two include files:
> 	ti, bfe, trm, stg, scd, aac, kbd, ie, idt, hfa, gfb, fb, dpt,
> 	cnw, aic, aha, ahb, adv
> and some of the mii phy drivers, plus some other trivial uses.
> 
> The only ones on the list that stand out are bfe and aac (the dpt
> optimization is only for EISA cards, and only for the EISA specific
> portions of the driver).  I do not know how much this optimization
> helps these devices, but they are the only ones that I see might be
> affected.  Simple benchmarks should be easy enough to do on aac and
> bfe.
> 
> Warner
> 
> [*] Yes, I know that slower CPUs are supported, and do still perform
> decently if you have enough memory.  This is an arbitrary cutoff for
> the cost-benefit analysis.

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.

Scott
Received on Sun May 29 2005 - 17:37:33 UTC