linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Pankaj Raghav <p.raghav@samsung.com>
To: hubcap@omnibond.com, brauner@kernel.org, martin@omnibond.com,
	willy@infradead.org, hch@lst.de, minchan@kernel.org,
	viro@zeniv.linux.org.uk, axboe@kernel.dk,
	akpm@linux-foundation.org, senozhatsky@chromium.org
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	devel@lists.orangefs.org, linux-fsdevel@vger.kernel.org,
	linux-block@vger.kernel.org, gost.dev@samsung.com,
	mcgrof@kernel.org, Pankaj Raghav <p.raghav@samsung.com>
Subject: [PATCH v3 0/3] remove page_endio() v3
Date: Tue, 11 Apr 2023 14:29:17 +0200	[thread overview]
Message-ID: <20230411122920.30134-1-p.raghav@samsung.com> (raw)
In-Reply-To: <CGME20230411122922eucas1p1ed50c7c4c98104f936e3057f975c72ac@eucas1p1.samsung.com>

It was decided to remove the page_endio() as per the previous RFC
discussion[1] of this series and move that functionality into the caller
itself. One of the side benefit of doing that is the callers have been
modified to directly work on folios as page_endio() already worked on
folios.

As Christoph is doing ZRAM cleanups[4] which will get rid of
page_endio() function usage, I removed the final patch that removes
page_endio()[5]. I will send it separately after rc-1 once the zram
cleanups are merged.

mpage changes were tested with a simple boot testing and running a fio
workload on ext2 filesystem. orangefs was tested by Mike Marshall
(No code changes since he tested).

Changes since v2:
- Dropped the zram patch
- Dropped the patch that removes page_endio() function from filemap
- Also split mpage_submit_bio into read and write counterparts (Christoph)

Changes since v1:
- Always chain the IO to the parent as it can never be NULL (Minchan)
- Added reviewed and tested by tags

Changes since RFC 2[2]:
- Call bio_put in zram bio end io handler (Still not Acked by hch[3])
- Call folio_set_error in mpage read endio error path (Willy)
- Directly call folio->mapping in mpage write endio error path (Willy)

[1] https://lore.kernel.org/linux-mm/ZBHcl8Pz2ULb4RGD@infradead.org/
[2] https://lore.kernel.org/linux-mm/20230322135013.197076-1-p.raghav@samsung.com/
[3] https://lore.kernel.org/linux-mm/8adb0770-6124-e11f-2551-6582db27ed32@samsung.com/
[4] https://lore.kernel.org/linux-block/20230404150536.2142108-1-hch@lst.de/T/#t
[5] https://lore.kernel.org/lkml/20230403132221.94921-6-p.raghav@samsung.com/

Pankaj Raghav (3):
  orangefs: use folios in orangefs_readahead
  mpage: split submit_bio and bio end_io handler for reads and writes
  mpage: use folios in bio end_io handler

 fs/mpage.c          | 66 +++++++++++++++++++++++++++++++--------------
 fs/orangefs/inode.c |  9 ++++---
 2 files changed, 51 insertions(+), 24 deletions(-)

-- 
2.34.1



       reply	other threads:[~2023-04-11 12:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20230411122922eucas1p1ed50c7c4c98104f936e3057f975c72ac@eucas1p1.samsung.com>
2023-04-11 12:29 ` Pankaj Raghav [this message]
     [not found]   ` <CGME20230411122923eucas1p27e097fa66db8e166d14658bc7c6f180b@eucas1p2.samsung.com>
2023-04-11 12:29     ` [PATCH v3 1/3] orangefs: use folios in orangefs_readahead Pankaj Raghav
     [not found]   ` <CGME20230411122923eucas1p1dfc182a2c785eeb362b9d670dfe3ba2f@eucas1p1.samsung.com>
2023-04-11 12:29     ` [PATCH v3 2/3] mpage: split submit_bio and bio end_io handler for reads and writes Pankaj Raghav
2023-04-11 12:30       ` Christoph Hellwig
     [not found]   ` <CGME20230411122924eucas1p16c6abcf91a3e04c6a0a225606ca0044d@eucas1p1.samsung.com>
2023-04-11 12:29     ` [PATCH v3 3/3] mpage: use folios in bio end_io handler Pankaj Raghav

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=20230411122920.30134-1-p.raghav@samsung.com \
    --to=p.raghav@samsung.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=devel@lists.orangefs.org \
    --cc=gost.dev@samsung.com \
    --cc=hch@lst.de \
    --cc=hubcap@omnibond.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=martin@omnibond.com \
    --cc=mcgrof@kernel.org \
    --cc=minchan@kernel.org \
    --cc=senozhatsky@chromium.org \
    --cc=viro@zeniv.linux.org.uk \
    --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