Re: [discuss] Re: 32-bit dma allocations on 64-bit platforms

[Andrea Arcangeli <andrea@suse.de>]

On Thu, Jun 24, 2004 at 11:13:11AM -0700, William Lee Irwin III wrote:
> This sounds like the more precise fix would be enforcing a stricter
> fallback criterion for pinned allocations. Pinned userspace would need
> zone migration if it's done selectively like this.

yes and "the stricter fallback criterion" is precisely called
lower_zone_reserve_ratio and it's included in the 2.4 mainline kernel
and this "stricter fallback criterion" doesn't exist in 2.6 yet.

I do apply it to non-pinned pages too because wasting tons of cpu in
memcopies for migration is a bad idea compared to reseving 900M of
absolutely critical lowmem ram on a 64G box. So I find the
pinned/unpinned parameter worthless and I apply "the stricter fallback
criterion" to all allocations in the same way, which is a lot simpler,
doesn't require substantial vm changes to allow migration of ptes,
anonymous and mlocked memory w/o passing through some swapcache and
without clearng ptes and most important I believe it's a lot more
efficient than migrating with bulk memcopies. Even on a big x86-64
dealing with the migration complexity is worthless, reserving the full
16M of dma zone makes a lot more sense.

The lower_zone_reserve_ratio algorithm scales back to the size of the
zones automatically autotuned at boot time and the balance-setting are in
functions of the imbalances found at boot time. That's the fundamental
difference with the sysctl that is fixed, for all zones, and it has no
clue on the size of the zones etc...

So in short with little ram installed it will be like mainline 2.6, with
tons of ram installed it will make an huge difference and it will
reserve up to _whole_ classzones to the users that cannot use the higher
zones, but 16M on a 16G box is nothing so nobody will notice any
regression anyways, only the befits will be noticeable in the otherwise
unsolvable corner cases (yeah, you could try to migrate ptes and other
stuff to solve them but that's incredibily inefficient compared to
throwing 16M or 800M at the problem on respectively 16G or 64G machines,
etc..).

the number aren't math exact with the 2.4 code, but you get an idea of
the order of magnitude.

BTW, I think I'm not the only VM guy who agrees this algo is needed,
For istance I recall Rik once included the lower_zone_reserve_ratio
patch in one of his 2.4 patches too.