[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-fsdevel
Subject:    Re: What sets PG_dirty?
From:       Daniel Phillips <news-innominate.list.linux.fsdevel () innominate ! de>
Date:       2000-11-20 20:11:32
[Download RAW message or body]

Rik van Riel wrote:
> 
> On Mon, 20 Nov 2000, Andrea Arcangeli wrote:
> > On Mon, Nov 20, 2000 at 05:42:48PM +1100, David Gibson wrote:
> > > [..] What am I missing?
> >
> > You should rename it to PG_protected.
> 
> Why?
> 
> PG_dirty is a perfectly adequate name. If we have a method
> to clean the page, it becomes freeable, if we don't, it won't
> become freeable.

The point is, right now the PG_dirty bit never gets set, so we aren't
really using it.  There are places where it's being tested as if it were
actually valid.  By happy accident this doesn't hurt anything - I showed
why in my previous post, though perhaps not very clearly. 

PG_dirty *should* be used, for example, to support deferred allocation
where we don't call the fs's writepage method until forced to do so by
memory pressure.  Another thing you might use it for is to discover the
write activity on a page - you can set the PG_dirty bit and clear the
hardware dirty bit, wait a while, and see if the dirty bit gets set
again.  If we ever get rid of buffers completely then PG_dirty *has* to
be used.

Right now it's apparently optional.  We are interpreting the state 'has
buffers and at least one buffers is dirty' as 'the page is dirty'.  I
think we need a little more precise definition of what the allowed
combinations of page and buffer states actually are, what they mean, and
who is allowed/supposed to change them where.  Since we don't actually
have a bug here, it sounds like yet another subproject for 2.5.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org

[prev in list] [next in list] [prev in thread] [next in thread]