Stefan Reinauer stepan@openbios.org writes:
- Eric W. Biederman ebiederman@lnxi.com [040601 09:53]:
Essentially. Although the pci devices don't vanish you likely can't use them because some of their BARS have values that 32bit kernels can't cope with. lspci should let you see that though. A 32bit kernel with PAE enabled could code but no one has written the code.
Are there any drawbacks to that solution? This should be addressed to the Linux kernel developers. Given the advantages this brings, this would probably something people would like to see.
struct resource {} needs to be defined in terms of u64 instead of unsigned long. I know just that tweak was discussed and there were some problems with that.
I don't have a problem with adding an option to disable this for 32bit kernels. I am just tired of optimizing 64bit machines for 32bit kernels.
The silver bullet would be an option in the cmos option table to trigger the one or the other behaviour.
Right that is what I was thinking.
Or maybe it is enough to just put the PCI BARs into 32bit address space whenever it fits there, taking the amount of RAM into regard.
Except for some very small filters that starts requiring a filter that is too smart. I think ultimately it is going to the bridge bars that are going to limit me. So I may only be able to apply this to prefetchable memory regions. But that should still cover the large mmio regions with 64bit BARs.
I agree it does not make sense to _optimize_ for 32bit kernels. Essentially there are two groups of potential LinuxBIOS users in this case: Those with small amounts of RAM (ie amd64 based embedded solutions) might use 32bit code because it's easy to test it on many PCs. Those with large amounts of RAM don't want to use a 32bit kernel anyways. With more than about 1G of RAM 32bit Linux performance breaks down noticably compared to the 64bit variant.
Interesting. Most of my customers have compute intensive apps and I don't think see the break down anywhere near that soon.
Eric