Messages in this thread | | | Date | Sat, 5 Jul 2008 00:02:59 +0200 | From | Pierre Ossman <> | Subject | Re: How to alloc highmem page below 4GB on i386? |
| |
On Fri, 4 Jul 2008 13:37:33 -0700 Arjan van de Ven <arjan@infradead.org> wrote:
> On Fri, 4 Jul 2008 22:23:23 +0200 > Pierre Ossman <drzeus-list@drzeus.cx> 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. [unhandled content-type:application/pgp-signature] | |