[lkml]   [2003]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:34    [W:0.262 / U:8.292 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site