Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1370940

Re: [PATCH 2/3] mm: filemap: only do access activations on reads

Show all headers | View raw

On Mon, Apr 04, 2016 at 02:22:33PM -0700, Andrew Morton wrote:
> On Mon,  4 Apr 2016 13:13:37 -0400 Johannes Weiner <hannes@cmpxchg.org> wrote:
> 
> > Andres Freund observed that his database workload is struggling with
> > the transaction journal creating pressure on frequently read pages.
> > 
> > Access patterns like transaction journals frequently write the same
> > pages over and over, but in the majority of cases those pages are
> > never read back. There are no caching benefits to be had for those
> > pages, so activating them and having them put pressure on pages that
> > do benefit from caching is a bad choice.
> 
> Read-after-write is a pretty common pattern: temporary files for
> example.  What are the opportunities for regressions here?

The read(s) following the write will call mark_page_accessed() and so
promote the pages if their data is in fact repeatedly accessed. That
makes sense, because the writes really don't say anything about the
cache-worthiness. One write followed by one read shouldn't mean the
data is strongly benefiting from being cached. Only multiple reads.

What complicates that a little bit is that when the multiple reads do
happen on write-instantiated pages, the pages might have already been
aged somewhat in between, whereas fresh-faulting reads start counting
accesses from the head of the LRU right away. If both have re-use
distances shorter than memory, the LRU offset of pages instantiated by
writes could push the second access past eviction.

In that case, they would likely get picked up by refault detection and
promoted after all. So it would be one more IO, but nothing permanent.

This is also somewhat compensated by the dirty cache delaying reclaim
and giving these pages another round-trip anyway - unless dirty limits
cause the pages to be written back before they reach the LRU tail.

It's really hard to tell whether that would even be an issue since it
depends on whether a workload matching those parameters even exist. A
synthetic test doesn't really say us much about that. I think all we
can do here is decide whether the cache semantics make logical sense.

One thing I proposed in the thread that would compensate for the LRU
offset of write-instantiated pages would be to set PageReferenced on
these pages but never call mark_page_accessed() from the write. This
wouldn't be perfect because the distance between write and read does
not necessarily predict the distance between the subsequent reads, but
it would mean that the first read would promote the pages, whereas
repeatedly written files would never be activated or refault-activate.

Would that make sense? Is there something I'm missing?

> Did you consider providing userspace with a way to hint "this file is
> probably write-then-not-read"?

Yes, but I'm not too confident in that working out :(

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH 0/3] mm: support bigger cache workingsets and protect against writes Johannes Weiner <hannes@cmpxchg.org> - 2016-04-04 19:20 +0200
  [PATCH 2/3] mm: filemap: only do access activations on reads Johannes Weiner <hannes@cmpxchg.org> - 2016-04-04 19:20 +0200
    Re: [PATCH 2/3] mm: filemap: only do access activations on reads Andrew Morton <akpm@linux-foundation.org> - 2016-04-04 23:30 +0200
      Re: [PATCH 2/3] mm: filemap: only do access activations on reads Rik van Riel <riel@redhat.com> - 2016-04-04 23:40 +0200
        Re: [PATCH 2/3] mm: filemap: only do access activations on reads Andrew Morton <akpm@linux-foundation.org> - 2016-04-05 00:00 +0200
        Re: [PATCH 2/3] mm: filemap: only do access activations on reads Johannes Weiner <hannes@cmpxchg.org> - 2016-04-05 20:00 +0200
      Re: [PATCH 2/3] mm: filemap: only do access activations on reads Johannes Weiner <hannes@cmpxchg.org> - 2016-04-05 00:50 +0200
  Re: [PATCH 0/3] mm: support bigger cache workingsets and protect  against writes Andres Freund <andres@anarazel.de> - 2016-04-04 21:00 +0200

csiph-web