From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: "Cédric Villemain" <cedric@2ndquadrant.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Konstantin Khlebnikov <koct9i@gmail.com>,
Wu Fengguang <fengguang.wu@intel.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Borislav Petkov <bp@alien8.de>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Johannes Weiner <hannes@cmpxchg.org>,
Rusty Russell <rusty@rustcorp.com.au>,
David Miller <davem@davemloft.net>,
Andres Freund <andres@2ndquadrant.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Dave Hansen <dave.hansen@intel.com>,
Michael Kerrisk <mtk.manpages@gmail.com>,
Linux API <linux-api@vger.kernel.org>,
Naoya Horiguchi <nao.horiguchi@gmail.com>
Subject: Re: [PATCH v2 2/4] mm: introduce fincore()
Date: Fri, 4 Jul 2014 12:31:07 -0400 [thread overview]
Message-ID: <20140704163107.GA17877@nhori> (raw)
In-Reply-To: <5816450.BPnLjGgtl5@obelix>
On Fri, Jul 04, 2014 at 05:15:59PM +0200, Cédric Villemain wrote:
> Le vendredi 4 juillet 2014 03:12:30 Christoph Hellwig a écrit :
> > On Thu, Jul 03, 2014 at 05:52:13PM -0400, Naoya Horiguchi wrote:
> > > This patch provides a new system call fincore(2), which provides
> > > mincore()- like information, i.e. page residency of a given file.
> > > But unlike mincore(), fincore() has a mode flag which allows us to
> > > extract detailed information about page cache like pfn and page
> > > flag. This kind of information is very helpful, for example when
> > > applications want to know the file cache status to control the IO
> > > on their own way.
> >
> > It's still a nasty multiplexer for multiple different reporting
> > formats in a single system call. How about your really just do a
> > fincore that mirrors mincore instead of piggybacking exports of
> > various internal flags (tags and page flags onto it.
We can do it in mincore-compatible way with FINCORE_BMAP mode.
If you choose it, you don't care about any details about other modes.
I don't make no default mode, but if we have a good reason, I'm OK
to set FINCORE_BMAP as default mode.
> The fincore à la mincore got some arguments against it too. It seems this
> implementations try (I've not tested nor have a close look yet) to
> answer both concerns : have details and also possible to have
> aggregation function not too expansive.
Correct, that's the motivation of this non-trivial interface.
This could finally obsoletes messy /proc/kpage{flags,count} and/or
/proc/pid/pagemap kind of things, and we will not have to collect
information over all these interfaces (so that's less expensive.)
Thanks,
Naoya Horiguchi
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: "Cédric Villemain" <cedric@2ndquadrant.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Konstantin Khlebnikov <koct9i@gmail.com>,
Wu Fengguang <fengguang.wu@intel.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Borislav Petkov <bp@alien8.de>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Johannes Weiner <hannes@cmpxchg.org>,
Rusty Russell <rusty@rustcorp.com.au>,
David Miller <davem@davemloft.net>,
Andres Freund <andres@2ndquadrant.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Dave Hansen <dave.hansen@intel.com>,
Michael Kerrisk <mtk.manpages@gmail.com>,
Linux API <linux-api@vger.kernel.org>,
Naoya Horiguchi <nao.horiguchi@gmail.com>
Subject: Re: [PATCH v2 2/4] mm: introduce fincore()
Date: Fri, 4 Jul 2014 12:31:07 -0400 [thread overview]
Message-ID: <20140704163107.GA17877@nhori> (raw)
In-Reply-To: <5816450.BPnLjGgtl5@obelix>
On Fri, Jul 04, 2014 at 05:15:59PM +0200, Cedric Villemain wrote:
> Le vendredi 4 juillet 2014 03:12:30 Christoph Hellwig a ecrit :
> > On Thu, Jul 03, 2014 at 05:52:13PM -0400, Naoya Horiguchi wrote:
> > > This patch provides a new system call fincore(2), which provides
> > > mincore()- like information, i.e. page residency of a given file.
> > > But unlike mincore(), fincore() has a mode flag which allows us to
> > > extract detailed information about page cache like pfn and page
> > > flag. This kind of information is very helpful, for example when
> > > applications want to know the file cache status to control the IO
> > > on their own way.
> >
> > It's still a nasty multiplexer for multiple different reporting
> > formats in a single system call. How about your really just do a
> > fincore that mirrors mincore instead of piggybacking exports of
> > various internal flags (tags and page flags onto it.
We can do it in mincore-compatible way with FINCORE_BMAP mode.
If you choose it, you don't care about any details about other modes.
I don't make no default mode, but if we have a good reason, I'm OK
to set FINCORE_BMAP as default mode.
> The fincore a la mincore got some arguments against it too. It seems this
> implementations try (I've not tested nor have a close look yet) to
> answer both concerns : have details and also possible to have
> aggregation function not too expansive.
Correct, that's the motivation of this non-trivial interface.
This could finally obsoletes messy /proc/kpage{flags,count} and/or
/proc/pid/pagemap kind of things, and we will not have to collect
information over all these interfaces (so that's less expensive.)
Thanks,
Naoya Horiguchi
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: "Cédric Villemain" <cedric@2ndquadrant.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Konstantin Khlebnikov <koct9i@gmail.com>,
Wu Fengguang <fengguang.wu@intel.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Borislav Petkov <bp@alien8.de>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Johannes Weiner <hannes@cmpxchg.org>,
Rusty Russell <rusty@rustcorp.com.au>,
David Miller <davem@davemloft.net>,
Andres Freund <andres@2ndquadrant.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Dave Hansen <dave.hansen@intel.com>,
Michael Kerrisk <mtk.manpages@gmail.com>,
Linux API <linux-api@vger.kernel.org>,
Naoya Horiguchi <nao.horiguchi@gmail.com>
Subject: Re: [PATCH v2 2/4] mm: introduce fincore()
Date: Fri, 4 Jul 2014 12:31:07 -0400 [thread overview]
Message-ID: <20140704163107.GA17877@nhori> (raw)
In-Reply-To: <5816450.BPnLjGgtl5@obelix>
On Fri, Jul 04, 2014 at 05:15:59PM +0200, Cédric Villemain wrote:
> Le vendredi 4 juillet 2014 03:12:30 Christoph Hellwig a écrit :
> > On Thu, Jul 03, 2014 at 05:52:13PM -0400, Naoya Horiguchi wrote:
> > > This patch provides a new system call fincore(2), which provides
> > > mincore()- like information, i.e. page residency of a given file.
> > > But unlike mincore(), fincore() has a mode flag which allows us to
> > > extract detailed information about page cache like pfn and page
> > > flag. This kind of information is very helpful, for example when
> > > applications want to know the file cache status to control the IO
> > > on their own way.
> >
> > It's still a nasty multiplexer for multiple different reporting
> > formats in a single system call. How about your really just do a
> > fincore that mirrors mincore instead of piggybacking exports of
> > various internal flags (tags and page flags onto it.
We can do it in mincore-compatible way with FINCORE_BMAP mode.
If you choose it, you don't care about any details about other modes.
I don't make no default mode, but if we have a good reason, I'm OK
to set FINCORE_BMAP as default mode.
> The fincore à la mincore got some arguments against it too. It seems this
> implementations try (I've not tested nor have a close look yet) to
> answer both concerns : have details and also possible to have
> aggregation function not too expansive.
Correct, that's the motivation of this non-trivial interface.
This could finally obsoletes messy /proc/kpage{flags,count} and/or
/proc/pid/pagemap kind of things, and we will not have to collect
information over all these interfaces (so that's less expensive.)
Thanks,
Naoya Horiguchi
next prev parent reply other threads:[~2014-07-04 16:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-03 21:52 [PATCH 0/4] mm: introduce fincore() v2 Naoya Horiguchi
2014-07-03 21:52 ` Naoya Horiguchi
2014-07-03 21:52 ` [PATCH v2 1/4] define PAGECACHE_TAG_* as enumeration under include/uapi Naoya Horiguchi
2014-07-03 21:52 ` Naoya Horiguchi
2014-07-04 1:16 ` Dave Chinner
2014-07-04 1:16 ` Dave Chinner
2014-07-04 1:41 ` Naoya Horiguchi
2014-07-04 1:41 ` Naoya Horiguchi
2014-07-03 21:52 ` [PATCH v2 2/4] mm: introduce fincore() Naoya Horiguchi
2014-07-03 21:52 ` Naoya Horiguchi
2014-07-04 10:12 ` Christoph Hellwig
2014-07-04 10:12 ` Christoph Hellwig
2014-07-04 15:15 ` Cédric Villemain
2014-07-04 16:31 ` Naoya Horiguchi [this message]
2014-07-04 16:31 ` Naoya Horiguchi
2014-07-04 16:31 ` Naoya Horiguchi
2014-07-03 21:52 ` [PATCH v2 3/4] selftests/fincore: add test code for fincore() Naoya Horiguchi
2014-07-03 21:52 ` Naoya Horiguchi
2014-07-03 21:52 ` [PATCH v2 4/4] man2/fincore.2: document general description about fincore(2) Naoya Horiguchi
2014-07-03 21:52 ` Naoya Horiguchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140704163107.GA17877@nhori \
--to=n-horiguchi@ah.jp.nec.com \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andres@2ndquadrant.com \
--cc=bp@alien8.de \
--cc=cedric@2ndquadrant.com \
--cc=dave.hansen@intel.com \
--cc=davem@davemloft.net \
--cc=fengguang.wu@intel.com \
--cc=hannes@cmpxchg.org \
--cc=hch@infradead.org \
--cc=kirill@shutemov.name \
--cc=koct9i@gmail.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mtk.manpages@gmail.com \
--cc=nao.horiguchi@gmail.com \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.