All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Ming Lei <ming.lei@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [RFC PATCH 2/2] block: split bio if the only bvec's length is > SZ_4K
Date: Mon, 11 Nov 2019 11:21:59 +0100	[thread overview]
Message-ID: <20191111102159.GA12709@lst.de> (raw)
In-Reply-To: <20191108101528.31735-3-ming.lei@redhat.com>

On Fri, Nov 08, 2019 at 06:15:28PM +0800, Ming Lei wrote:
> 64K PAGE_SIZE is popular on ARM64 or other ARCHs, and 64K has been big
> enough to break some devices probably, so change the logic to split bio
> if the only bvec's length is > SZ_4K instead of PAGE_SIZE.

I don't think this makes sense as-is given that blk_queue_max_hw_sectors,
blk_queue_max_segment_size and co all check for a minimum of PAGE_SIZE
and warn otherwise, and blk_bio_segment_split uses PAGE_SIZE for
its short cut as well. So I don't think this has been a problem in
practice, and if it was this patch is not enough.

So either we leave things as is, or we need to do a real audit for
code using PAGE_SIZE as the minimum I/O granularity and replace it
everywhere a well as updating the documentation.  Which might be a good
thing given that variable sized limits are weird.

  reply	other threads:[~2019-11-11 10:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08 10:15 [PATCH 0/2] block: two fixes on avoiding bio splitting Ming Lei
2019-11-08 10:15 ` [PATCH 1/2] block: still try to split bio if the bvec crosses pages Ming Lei
2019-11-08 10:15 ` [RFC PATCH 2/2] block: split bio if the only bvec's length is > SZ_4K Ming Lei
2019-11-11 10:21   ` Christoph Hellwig [this message]
2019-11-08 14:00 ` [PATCH 0/2] block: two fixes on avoiding bio splitting Jens Axboe

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=20191111102159.GA12709@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    /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.