On Sun, Mar 27, 2005 at 05:31:13PM +0200, Michael S. Tsirkin wrote: > For Tavor, MTTs for FMR are separate from regular MTTs, and are reserved > at driver initialization. This is done to limit the amount of > virtual memory needed to map the MTTs. > For Arbel, there's no such limitation, and all MTTs and MPTs may be used > for FMR or for regular MR. > It would be easy to remove the limitation for Tavor for 64-bit systems, where > it's feasible to ioremap the whole MTT table. Let me know if this is > of interest.
I have the impression most of this forum is currently running "native" bits on 64-bit arches: sparc64, amd64, ia64, ppc64. I.e. this feature would be well tested if those 4 arches are enabled. I'll assert that's NOT how gen2 will get used once distro's pick it up. Historically, ia32 was 95% of the mainline distro's business. While I don't expect that to change significantly by next year, I do expect new *Linux* x86 servers to be running a 64-bit OS and support both 32-bit and 64-bit user space. It seems most 2U/2-socket boxes already support more than 4GB of RAM and it would make sense the default OS be a 64-bit one. However, that's just speculation. I have no visibility what the x86 side of HP (or other vendors) is doing next year. grant _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
