Because 64M of AGP memory divided by 4K pages is 16K. That is, the
underlying problem seems to be AGP drivers using order 0 allocations.
I'm looking.
Do note also that this means that Venki's change would not constitite a
correct/final fix. Sure, caching the last entry speeds up traversing a
16K entry list but the issue is that there shouldn't be a 16K entry
list. Through AGP, or maybe even by coalescing entries in the PAT list
if that's at all possible (I guess it's not really).
Even if such a more fundamental fix isn't (easily) available, the PAT
code already comments that the list, which is sorted by ->start value,
is expected to be short, and should be turned into an rbtree if it isn't
which might be slightly less of a bandaid.
Dave Airlie (as the MAINTAINERS entry) can't be arsed to answer email it
seems so I've added Dave Jones for a possible comment from the AGP side.
If I'm reading this right upto now, still many AGP driver (among which
my amd-k7-agp) are affected.
In the short run and if I'm not just mistaken, the best fix might be to
make PAT dependent on not having a dumb AGP driver (but as said, still
looking).
Note that my chipset is capable of a 2G AGP aperture. That's 512K pages
if fully used, 256K for 1G, 128K for 512M, ...
Rene.
--
