Messages in this thread | | | Date | Sat, 5 Apr 2003 23:07:10 -0800 | From | William Lee Irwin III <> | Subject | Re: objrmap and vmtruncate |
| |
On Sat, Apr 05, 2003 at 04:17:58PM -0800, Andrew Morton wrote: > There are perhaps a few things we can do about that. > It's only a problem on the kooky highmem boxes, and they need page clustering > anyway. > And this is just another instance of "lowmem pinned by highmem pages" which > could be solved by unmapping (and not necessarily reclaiming) the highmem > pages. But that's a pretty lame thing to do.
I've actually liked this approach, despite not being terribly highly performant, on the grounds it is relatively non-invasive, and that once it's in place, various stronger (and more invasive) space reduction techniques become optimizations instead of workload feasibility patches. The fact it generalizes to other (non-highmem) situations is also good.
I'm not terribly attached to it, but since there is some mention of it, thought it worth mentioning that there is _some_ middle ground that I (as one of the "big highmem box bad guys") find acceptable.
I'm largely anticipating out-of-tree patches will be needed to run these machines anyway and am prepared (in nontrivial senses; significant amounts of my time in the future are allocated to maintaining and implementing the things needed for it) to take on some of the maintenance load to keep workloads running and running performantly on these boxen (specifically pgcl; other patches [e.g. shpte] have other maintainers). It's probably not the best thing to say in the face of the possibility of a truly immense maintenance load, but it is true.
-- 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/
| |