From: Michal Hocko <mhocko@suse.com>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: willy@infradead.org, Jan Kara <jack@suse.cz>,
Hugh Dickins <hughd@google.com>, Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Linux MM <linux-mm@kvack.org>
Subject: Re: [PATCH] mm: add vm event for page cache miss
Date: Tue, 2 Apr 2019 09:44:59 +0200 [thread overview]
Message-ID: <20190402074459.GP28293@dhcp22.suse.cz> (raw)
In-Reply-To: <CALOAHbASRo1xdkG62K3sAAYbApD5yTt6GEnCAZo1ZSop=ORj6w@mail.gmail.com>
On Tue 02-04-19 15:38:02, Yafang Shao wrote:
> On Tue, Apr 2, 2019 at 3:23 PM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Tue 02-04-19 14:15:20, Yafang Shao wrote:
> > > We found that some latency spike was caused by page cache miss on our
> > > database server.
> > > So we decide to measure the page cache miss.
> > > Currently the kernel is lack of this facility for measuring it.
> >
> > What are you going to use this information for?
> >
>
> With this counter, we can monitor pgcachemiss per second and this can
> give us some informaton that
> whether the database performance issue is releated with pgcachemiss.
> For example, if this value increase suddently, it always cause latency spike.
>
> What's more, I also want to measure how long this page cache miss may cause,
> but this seems more complex to implement.
Aren't tracepoints a better fit with this usecase? You not only get the
count of misses but also the latency. Btw. latency might be caused also
for the minor fault when you hit lock contention.
>
>
> > > This patch introduces a new vm counter PGCACHEMISS for this purpose.
> > > This counter will be incremented in bellow scenario,
> > > - page cache miss in generic file read routine
> > > - read access page cache miss in mmap
> > > - read access page cache miss in swapin
> > >
> > > NB, readahead routine is not counted because it won't stall the
> > > application directly.
> >
> > Doesn't this partially open the side channel we have closed for mincore
> > just recently?
> >
>
> Seems I missed this dicussion.
> Could you pls. give a reference to it?
The long thread starts here http://lkml.kernel.org/r/nycvar.YFH.7.76.1901051817390.16954@cbobk.fhfr.pm
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-04-02 7:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-02 6:15 Yafang Shao
2019-04-02 7:23 ` Michal Hocko
2019-04-02 7:38 ` Yafang Shao
2019-04-02 7:44 ` Michal Hocko [this message]
2019-04-02 7:49 ` Michal Hocko
2019-04-02 7:56 ` Yafang Shao
2019-04-02 7:54 ` Yafang Shao
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=20190402074459.GP28293@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=laoar.shao@gmail.com \
--cc=linux-mm@kvack.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox