All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.