On Tue, Mar 10, 2009 at 10:21:18PM +0200, Pierre Ossman wrote:
> On Tue, 10 Mar 2009 21:11:55 +0800
> Wu Fengguang <fengguang.wu@intel.com> wrote:
>
> > If we run eatmem or the following commands to take up free memory,
> > the missing pages will show up :-)
> >
> >         dd if=/dev/zero of=/tmp/s bs=1M count=1 seek=1024
> >         cp /tmp/s /dev/null
> >
>
> Not here, which now means I've "found" all of my missing 170 MB.
>
> On 2.6.27, when I fill the page cache I still get over 90 MB left in
> "noflags":
>
> 0x20000	     24394       95  _________________n  noflags
>
> The same thing with 2.6.26 almost completely drains it:
>
> 0x20000	      3697       14  _________________n  noflags
>
> Another interesting data point is that those 80 MB always seem to be
> the exact same number of pages every boot.

This 80MB noflags pages together with the below 80MB lru pages are
very close to the missing page numbers :-) Could you run the following
commands on fresh booted 2.6.27 and post the output files? Thank you!

        dd if=/dev/zero of=/tmp/s bs=1M count=1 seek=1024
        cp /tmp/s /dev/null

        ./page-flags > flags
        ./page-areas =0x20000 > areas-noflags
        ./page-areas =0x00020 > areas-lru

The attached page-areas.c can do the above exact flags matching.

> After that, a comparison shows that this row is in 2.6.27, but not
> 2.6.26:
>
> 0x00020      20576       80  _____l____________  lru
>
> Unfortunately there are about 170 MB of missing memory, not 80. So we
> probably need to dig deeper. But does the above say anything to you?

> I had to remove PG_swapbacked and PG_private2 as 2.6.26/2.6.27 didn't
> have those bits.

Ah sorry! I forgot to switch the tree back to 2.6.27 to run a test.

Thanks,
Fengguang