Messages in this thread | | | Date | Thu, 24 Jun 2004 20:27:37 +0200 | From | Andrea Arcangeli <> | Subject | Re: [discuss] Re: 32-bit dma allocations on 64-bit platforms |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |