Date: Wed, 26 Apr 2006 10:25:02 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: scottl@samsco.org Cc: src-committers@FreeBSD.org, bde@zeta.org.au, jhb@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, mj@feral.com Subject: Re: cvs commit: src/sys/dev/bce if_bcereg.h Message-ID: <20060426.102502.11595340.imp@bsdimp.com> In-Reply-To: <20060426.101245.90994186.imp@bsdimp.com> References: <20060425223519.F65802@ns1.feral.com> <444F0923.8050508@samsco.org> <20060426.101245.90994186.imp@bsdimp.com>
index | next in thread | previous in thread | raw e-mail
In message: <20060426.101245.90994186.imp@bsdimp.com>
M. Warner Losh <imp@bsdimp.com> writes:
: In message: <444F0923.8050508@samsco.org>
: Scott Long <scottl@samsco.org> writes:
: : Matthew Jacob wrote:
: : >
: : >> Supporting sizes >= 4G sounds unreasonable. How can a single device
: : >> need or even address so much space, even on 64-bit arches? For vm,
: : >> virtual memory is sort of a device, but even it is limited to 4G on
: : >> 32-bit arches, and PAE on i386 isn't pessimized by using a larger than
: : >> necessary vm_size_t.
: : >
: : >
: : > I have need to support and help people sell machines that use 32GB of
: : > directly addressable memory. In fact, the EM64T cheat will shortly
: : > become an embarrasment to Intel when people find out that EM64T with PAE
: : > is *not* the same as Opteron (36 vs. 40).
: : >
: : > I'm afraid I don't understand the 'unreasonable' argument here. Linux is
: : > eating your lunch today. Do you want it to eat your dessert as well?
: : >
: : > -matt
: : >
: :
: : bus_size_t is used for things like measuring transfer segment size.
: : There is little chance that Linux, Windows, FreeBSD, or any other OS
: : is ever going to try to DMA more than 2^32 bytes of data in a single
: : bus transaction. Maybe you could contrive a silly infiniband device
: : to do it. Anyways, it has no bearing on whether the CPU, memory
: : controller, or PCI buses can do 64 bit addressing.
:
: bus_size_t is for differences between two bus_addr_t quantities, since
: it specifies the size of resources on a bus. It is also used for
: transfer sizes and the like. That's why I think it should be a 64-bit
: quantity: 64-bit - 64-bit = 64-bit.
I should have added that if there's a substantial penalty for going to
64-bits, then we should avoid it. My objections are based on the
resource allocation perspective, not the DMA segment size perspective.
It will be a while before video cards have > 4G window of resources
presented to the system. While an individual DMA transfer on the
PCI-E bus may not cross such a boundary, I bleieve that individual
resources can consume more than 4G. Our PCI code doesn't handle BARs
that are > 4G in size correctly, but it does handle BARs that are
mapped anywhere in a 64-bit address space.
So my argument is more theoretical than practical at this point.
Since the other consensus appears to be leave it alone, I'll be quiet
now.
Warner
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060426.102502.11595340.imp>