linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: p.raghav@samsung.com, hare@suse.de, kbusch@kernel.org,
	david@fromorbit.com, neilb@suse.de
Cc: mcgrof@kernel.org, gost.dev@samsung.com,
	linux-block@vger.kernel.org, linux-mm@kvack.org,
	patches@lists.linux.dev
Subject: [RFC] swapfile: disable swapon for bs > ps devices
Date: Wed, 26 Jun 2024 17:09:23 -0700	[thread overview]
Message-ID: <20240627000924.2074949-1-mcgrof@kernel.org> (raw)

Devices which have a requirement for bs > ps cannot be supported for
swap as swap still needs work. Once the block device cache sets the
min order for block devices [0] we need this stop gap otherwise all
swap operations are rejected.

[0] https://lore.kernel.org/all/20240510102906.51844-6-hare@kernel.org/T/#md09501306c649dd84db0a711f9359570c17a197f

Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---

This is super *way* forward looking after LBS patches and once we square away
how to support things on the block device cache. Only then does it make
sense to start to consider this. But this is just a stop gap.

But if you think about it, in practice since we are going forward with a
world where we have AWUPF >= NPWG to enable the physical_block_size to
be >= NPWG, the corner case we want to help users *try* to avoid is to enable
swap not when the LBA format is > PAGE_SIZE (although for sport we can
support that) but when the NPWG > PAGE_SIZE. So we'd warn about that until
swap gets a facelift. That is 4k writes will work for devices with 4k
LBA format for example but NPWG = 16k, they would work with a RMW
penalty, just as RMWs today happen with drives formatted with 512 LBA
format and today's default world of 4k IU.

As it turns out we have no topology information for the IU today.  It used
to be that physical_block_size used to have a language about RMW.
During the 2024 LSFMM thread about Large Block for IO that Hannes
proposed we reviewed this discrepancy [1] but we seemed to conclude then
that no changes are required.

I'm starting to think that exposing the IU might make sense now. The
below would not capture the case of the IU > PAGE_SIZE, in theory that
should work but then its just RMWs, but users likely should be informed
it is stupid for them to do that. The other more important use case
would be for STATX_DIOALIGN for the dio_offset_align. That seems
incorrect today even for existing drives with 4k IU and 512 LBA format.

Thoughts?

[1] https://lore.kernel.org/all/ZekfZdchUnRZoebo@bombadil.infradead.org/

 mm/swapfile.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index 2f5203aa2d2c..9ff168760bc2 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -3153,6 +3153,11 @@ SYSCALL_DEFINE2(swapon, const char __user *, specialfile, int, swap_flags)
 		goto bad_swap_unlock_inode;
 	}
 
+	if (mapping_min_folio_order(mapping) > 0) {
+		error = -EINVAL;
+		goto bad_swap_unlock_inode;
+	}
+
 	/*
 	 * Read the swap header.
 	 */
-- 
2.43.0



                 reply	other threads:[~2024-06-27  0:09 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20240627000924.2074949-1-mcgrof@kernel.org \
    --to=mcgrof@kernel.org \
    --cc=david@fromorbit.com \
    --cc=gost.dev@samsung.com \
    --cc=hare@suse.de \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=neilb@suse.de \
    --cc=p.raghav@samsung.com \
    --cc=patches@lists.linux.dev \
    /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