Messages in this thread |  | | | Date | Thu, 24 Jun 2004 15:08:23 -0700 | | From | William Lee Irwin III <> | | Subject | Re: [discuss] Re: 32-bit dma allocations on 64-bit platforms |
| |
On Thu, Jun 24, 2004 at 02:54:41PM -0700, Andrew Morton wrote: > We decided earlier this year that the watermark stuff should be > forward-ported in toto, but I don't recall why. Nobody got around to doing > it because there have been no bug reports. > It irks me that the 2.4 algorithm gives away a significant amount of > pagecache memory. It's a relatively small amount, but it's still a lot of > memory, and all the 2.6 users out there at present are not reporting > problems, so we should not penalise all those people on behalf of the few > people who might need this additional fallback protection. > It should be runtime tunable - that doesn't seem hard to do. All the > infrastructure is there now to do this. > Note that this code was sigificantly changed between 2.6.5 and 2.6.7. > First thing to do is to identify some workload which needs the patch. > Without that, how can we test it?
That does sound troublesome, especially since it's difficult to queue up the kinds of extended stress tests needed to demonstrate the problems. The prolonged memory pressure and so on are things that we've unfortunately had to wait until extended runtime in production to see. =( The underutilization bit is actually why I keep going on and on about the pinned pagecache relocation; it resolves a portion of the problem of pinned pages in lower zones without underutilizing RAM, then once pinned user pages can arbitrarily utilize lower zones, pinned kernel allocations (which would not be relocatable) can be denied fallback entirely without overall underutilization. I've actually already run out of ideas here, so just people just saying what they want me to write might help. Tests can be easily contrived (e.g. fill a swapless box' upper zones with file-backed pagecache, then start allocating anonymous pages), but realistic situations are much harder to trigger.
-- wli - 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/
|  |