Re: Re : Re : Re : sparsemem usage

[Andy Whitcroft]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/