Date: Wed, 25 May 2005 11:19:45 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: nyan@jp.FreeBSD.org Cc: arch@freebsd.org Subject: Re: [RFC] remove bus_memio.h and bus_pio.h Message-ID: <20050525.111945.41668351.imp@bsdimp.com> In-Reply-To: <20050525.212009.71136852.nyan@jp.FreeBSD.org> References: <20050525.212009.71136852.nyan@jp.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20050525.212009.71136852.nyan@jp.FreeBSD.org>
Takahashi Yoshihiro <nyan@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050525.111945.41668351.imp>