All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Daniel Phillips <phillips@arcor.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Race in shrink_cache
Date: Thu, 05 Sep 2002 11:51:15 -0700	[thread overview]
Message-ID: <3D77A7A3.FBA1C598@zip.com.au> (raw)
In-Reply-To: E17n1ZQ-00069v-00@starship

Daniel Phillips wrote:
> 
> ..
> On the other hand, if what you want is a private list that page_cache_release
> doesn't act on automatically, all you have to do is set the lru state to zero,
> leave the page count incremented and move to the private list.  You then take
> explicit responsibility for freeing the page or moving it back onto a
> mainstream lru list.

That's the one.  Page reclaim speculatively removes a chunk (typically 32) of
pages from the LRU, works on them, and puts back any unfreeable ones later
on.  And the rest of the VM was taught to play correctly with pages that
can be off the LRU.  This was to avoid hanging onto the LRU lock while
running page reclaim.

And when those 32 pages are speculatively removed, their refcounts are
incremented.  Maybe that isn't necessary - I'd need to think about
that.  If it isn't, then the double-free thing is fixed.  If it is
necessary then then lru-adds-a-ref approach is nice, because shrink_cache
doesn't need to page_cache_get each page while holding the LRU lock,
as you say.

  reply	other threads:[~2002-09-05 18:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-05  5:04 Race in shrink_cache Daniel Phillips
2002-09-05  6:36 ` Andrew Morton
2002-09-05  6:36   ` Daniel Phillips
2002-09-05  7:07     ` Andrew Morton
2002-09-05  7:28       ` Daniel Phillips
2002-09-05  7:53         ` Andrew Morton
2002-09-05 18:41           ` Daniel Phillips
2002-09-05 18:51             ` Andrew Morton [this message]
2002-09-05 19:08               ` Daniel Phillips
2002-09-05 19:22                 ` Andrew Morton
2002-09-05 20:00                   ` Daniel Phillips
2002-09-05 13:33     ` Rik van Riel

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=3D77A7A3.FBA1C598@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillips@arcor.de \
    /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.