Date: Tue, 25 Apr 2006 23:46:11 -0600 From: Scott Long <scottl@samsco.org> To: Matthew Jacob <mj@feral.com> Cc: src-committers@FreeBSD.org, jhb@FreeBSD.org, Bruce Evans <bde@zeta.org.au>, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Warner Losh <imp@bsdimp.com> Subject: Re: cvs commit: src/sys/dev/bce if_bcereg.h Message-ID: <444F0923.8050508@samsco.org> In-Reply-To: <20060425223519.F65802@ns1.feral.com> References: <444E7750.206@samsco.org> <200604251540.00170.jhb@freebsd.org> <444E7BFE.4040800@samsco.org> <20060425.173236.74726638.imp@bsdimp.com> <444EB6A1.3060901@samsco.org> <20060426103623.M1847@epsplex.bde.org> <20060425223519.F65802@ns1.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?444F0923.8050508>