On Tue 02-04-19 15:38:02, Yafang Shao wrote: > On Tue, Apr 2, 2019 at 3:23 PM Michal Hocko <mhocko@xxxxxxxx> 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@xxxxxxxxxxxxx -- Michal Hocko SUSE Labs
