On Fri, 4 Jul 2008 13:37:33 -0700 Arjan van de Ven wrote: > On Fri, 4 Jul 2008 22:23:23 +0200 > Pierre Ossman wrote: > > > > I was under the impression that the PCI bus was utterly incapable of > > any larger address than 32 bits? But perhaps you only consider PCIE > > stuff high-perf. :) > > actually your impression is not correct. There's a difference between > how many physical bits the bus has, and the logical data. Specifically, > PCI (and PCIE etc) have something that's called "Dual Address Cycle", > which is a pci bus transaction that sends the 64 bit address using 2 > cycles on the bus even if the buswidth is 32 bit (logically). > Ah, I see. I have to admit to only have read the PCI spec briefly. :) Still, the devices I'm poking have 32-bit fields, so the limitation is still there for my case. > > > > The strange thing is that I keep getting pages from > 4GB all the > > time, even on a loaded system. I would have expected mostly getting > > pages below that limit as that's where most of the memory is. Do you > > have any insight into which areas tend to fill up first? > > ok this is tricky and goes way deep into buddy allocator internals. > On the highest level (2Mb chunks iirc, but it could be a bit or > two bigger now) we allocate top down. But once we split such a top level > chunk up, inside the chunk we allocate bottom up (so that the scatter > gather IOs tend to group nicer). > In addition, the kernel will prefer allocating userspace/pagecache > memory from highmem over lowmem, out of an effort to keep memory > pressure in the lowmem zones lower. > For the test I'm playing with, in does a second order allocation, which I suppose has good odds of finding a suitable hole somewhere in the upper GB. Ah well, I suppose this highmem business will eventually blow over. ;) Thanks -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption.