Re : Re : Re : sparsemem usage
From: moreau francis
Date: Fri Aug 11 2006 - 08:52:33 EST
Andy Whitcroft wrote:
> It does produce real numbers, it tells you how many reserved pages you
> have. The places that this is triggered we are interested in why we
> have no memory left. We are not interested in how many pages are known
> but reserved as against how many pages are backed by page*'s but are
> really holes; they are mearly pages we can't use out of the total we are
> tracking. We care about how many are not reserved, and how many of
> those are available.
> It would be 'as simple' as adding a PG_real page bit except for two things:
> 1) page flags bits are seriously short supply; there are some 24
> available of which 22 are in use. Any new user of a bit would have to
> be an extremely valuable change with major benefit to the kernel, and
It's indeed an issue. Could we instead use a combination of flags
that can't happen together. For example PG_Free|PG_Reserved ?
> 2) if you were to try and populate a PG_real flag it would need to be
> populated for _all_ architectures (and there are a lot) for it to be of
> any use. As you have already noted there is no consistent way to find
> out whether a page is ram so it would be major exercise to get these
> bits setup during boot.
> I think we should take (2) as a hint here. If we don't have a
> consistent interface for finding whether a page is real or not, we
> obviously have no general need of that information in the kernel.
or maybe _because_ we don't have a consistent interface for finding
whether a page is real or not, we end up with a strange thing called
page_is_ram() which could be the same for all arch and be implemented
BTW, can you try in a linux tree:
$ grep -r page_is_ram arch/
and see how it's implemented...
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/