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

From: M. Warner Losh (imp_at_bsdimp.com)
Date: 05/25/05

  • Next message: Marcel Moolenaar: "Re: [RFC] remove bus_memio.h and bus_pio.h" 
    Date: Wed, 25 May 2005 11:19:45 -0600 (MDT)
To: nyan@jp.FreeBSD.org

    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.
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Marcel Moolenaar: "Re: [RFC] remove bus_memio.h and bus_pio.h"

    Relevant Pages

    • Re: [RFC] remove bus_memio.h and bus_pio.h
      ... M. Warner Losh wrote: ... like this from MI drivers at least. ... > makes no sense to do any optimization at all, ... Well, in extreme cases, one could make the ...
      (freebsd-arch)
    • Re: [PATCH] Document Linuxs memory barriers [try #2]
      ... On Wednesday, March 08, 2006 5:27 pm, Linus Torvalds wrote: ... validating just a few drivers, it seems to be a good tradeoff. ... we added (though it's much less of an optimization than read_relaxed() ... So ultimately mmiowb() is the only thing drivers really have to care ...
      (Linux-Kernel)
    • RE: RAID 0 and the formatting of Partitions - Crossposted
      ... WHQL-windows hardware quality labs has not tested and optimzed SATA drivers, ... > before loading the operating system, I'm surprised you chose SATA,,Tests on ... > driver optimization. ...
      (microsoft.public.windowsxp.general)
    • RE: RAID 0 and the formatting of Partitions - Crossposted
      ... WHQL-windows hardware quality labs has not tested and optimzed SATA drivers, ... > before loading the operating system, I'm surprised you chose SATA,,Tests on ... > driver optimization. ...
      (microsoft.public.win2000.hardware)
    • RE: RAID 0 and the formatting of Partitions - Crossposted
      ... WHQL-windows hardware quality labs has not tested and optimzed SATA drivers, ... > before loading the operating system, I'm surprised you chose SATA,,Tests on ... > driver optimization. ...
      (microsoft.public.windowsxp.hardware)