Re: [PATCH 0/4] pagecache scanning with /proc/kpagecache

[Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>]

On Wed, May 21, 2014 at 03:42:50PM -0700, Andrew Morton wrote:
> On Tue, 20 May 2014 22:26:30 -0400 Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> wrote:
> 
> > This patchset adds a new procfs interface to extrace information about
> > pagecache status. In-kernel tool tools/vm/page-types.c has already some
> > code for pagecache scanning without kernel's help, but it's not free
> > from measurement-disturbance, so here I'm suggesting another approach.
> 
> I'm not seeing much explanation of why you think the kernel needs this.
> The overall justification for a change is terribly important so please
> do spend some time on it.

OK. Now I'm developing a patchset which improves memory error (and IO error
in next version) reporting on dirty pagecache (to avoid bad-data consumption.)
The essense of this patchset is that we remember error information on page
cache tree and users need to know which page cache is affected by error.
This is the reason why I need this feature.
# I separate this part from memory error reporting patchset and posted at
# first because I noticed Konstantin's patch just a few days ago and I found
# the person who has the same interest of mine :)

I understand adding procfs interface itself needs much care, so I don't
persist in this specific interface if there're better options. Now I'm
reserching other options Konstantin suggesting.

> As I don't *really* know what the patch is for, I can't comment a lot
> further, but...
> 
> 
> A much nicer interface would be for us to (finally!) implement
> fincore(), perhaps with an enhanced per-present-page payload which
> presents the info which you need (although we don't actually know what
> that info is!).

page/pfn of each page slot and its page cache tag as shown in patch 4/4.

> This would require open() - it appears to be a requirement that the
> caller not open the file, but no reason was given for this.
> 
> Requiring open() would address some of the obvious security concerns,
> but it will still be possible for processes to poke around and get some
> understanding of the behaviour of other processes.  Careful attention
> should be paid to this aspect of any such patchset.

Sorry if I missed your point, but this interface defines fixed mapping
between file position in /proc/kpagecache and in-file page offset of
the target file. So we do not need to use seq_file mechanism, that's
why open() is not defined and default one is used.
The same thing is true for /proc/{kpagecount,kpageflags}, from which
I copied/pasted some basic code.

Thanks,
Naoya

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>