moreau francis wrote:
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 ?
You'd need to audit all other users of the bits you wanted to borrow to
check they would understand. Like if you used PG_buddy (which I assume
is what you are referring to above) then you'd get non-real memory
getting merged into your buddies. Badness.
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
very simply.
BTW, can you try in a linux tree:
$ grep -r page_is_ram arch/
and see how it's implemented...
Well it depends how you look at it. You are going to need to know which
pages are ram in each architecture to set the bits in the page*'s to
tell us later. So the problem is the same problem. We don't
necessarily have the information for all architectures. As we don't use
this for anything its questionable whether we need it.
Feel free to try and figure it out for all these architectures :).
-apw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
