Re: [RFC][PATCH 4/4] vm-mapped-x-active-lists
From: Nick Piggin
Date: Tue Mar 09 2004 - 02:25:41 EST
William Lee Irwin III wrote:
On Tue, Mar 09, 2004 at 05:06:37PM +1100, Nick Piggin wrote:
Not sure to be honest, I haven't looked at it :\. I'm not really
sure if the rmap mitigation direction is just a holdover until
page clustering or intended as a permanent feature...
Either way, I trust its proponents will take the onus for regressions.
Actually, anobjrmap does wonderful things wrt. liberating pgcl
internals from some very frustrating complications having to do with
assumptions of a 1:1 correspondence between pte pages and struct pages,
so I would regard work in the direction of anobjrmap as useful to
advance the state of page clustering regardless of its rmap mitigation
overtones. The "partial" objrmap is actually insufficient to clean up
this assumption, and introduces new failure modes I don't like (which
it is in fact not necessary to do; aa's code is very close to doing the
partial-but-insufficient-for-pgcl objrmap properly apart from trying to
allocate more pte_chains than necessary and not falling back to the vma
lists for linear/nonlinear mapping mixtures). The current port has some
code to deal with this I'm extremely eager to dump as soon as things
such as anobjrmap etc. make it possible, if they're merged.
Current efforts are now a background/spare time affair centering around
non-i386 architectures and driver audits.
OK. I had just noticed that the people complaining about rmap most
are the ones using 4K page size (x86-64 uses 4K, doesn't it?). Not
that this fact means it is OK to ignore them problem, but I thought
maybe pgcl might solve it in a more general way.
I wonder how much you gain with objrmap / anobjrmap on say a 64K page
architecture?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/