linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: David Sterba <dsterba@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>, Chris Mason <clm@fb.com>,
	Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>,
	linux-btrfs@vger.kernel.org, Matthew Wilcox <willy@infradead.org>,
	linux-mm@kvack.org
Subject: Re: [PATCH 08/16] btrfs: stop setting PageError in the data I/O path
Date: Tue, 30 May 2023 07:45:47 +0200	[thread overview]
Message-ID: <20230530054547.GA5825@lst.de> (raw)
In-Reply-To: <20230529175210.GL575@twin.jikos.cz>

On Mon, May 29, 2023 at 07:52:10PM +0200, David Sterba wrote:
> On Tue, May 23, 2023 at 10:13:14AM +0200, Christoph Hellwig wrote:
> > PageError is not used by the VFS/MM and deprecated.
> 
> Is there some reference other than code? I remember LSF/MM talks about
> writeback, reducing page flags but I can't find anything that would say
> that PageError is not used anymore. For such core changes in the
> neighboring subysystems I kind of rely on lwn.net, hearsay or accidental
> notice on fsdevel.
> 
> Removing the Error bit handling looks overall good but I'd also need to
> refresh my understanding of the interactions with writeback.

willy is the driving force behind the PageErro removal, so maybe he
has a coherent writeup.  But the basic idea is:

 - page flag space availability is limited, and killing any one we can
   easily is a good thing
 - PageError is not well defined and not part of any VM or VFS contract,
   so in addition to freeing up space it also generally tends to remove
   confusion.


       reply	other threads:[~2023-05-30  5:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230523081322.331337-1-hch@lst.de>
     [not found] ` <20230523081322.331337-9-hch@lst.de>
     [not found]   ` <20230529175210.GL575@twin.jikos.cz>
2023-05-30  5:45     ` Christoph Hellwig [this message]
2023-05-30  6:08       ` Matthew Wilcox
2023-05-30 13:34         ` David Sterba
2023-05-30 14:26           ` Christoph Hellwig

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=20230530054547.GA5825@lst.de \
    --to=hch@lst.de \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=dsterba@suse.cz \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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