All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Yi Zhang <yi.zhang@redhat.com>,
	Luis Chamberlain <mcgrof@kernel.org>,
	John Garry <john.g.garry@oracle.com>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH] block: make queue limits workable in case of 64K PAGE_SIZE
Date: Mon, 6 Jan 2025 09:20:01 +0800	[thread overview]
Message-ID: <Z3svwejnonFmsY8q@fedora> (raw)
In-Reply-To: <1b1bf316-359a-4bec-8195-0152cd706001@acm.org>

On Fri, Jan 03, 2025 at 02:12:36PM -0800, Bart Van Assche wrote:
> On 1/2/25 6:01 PM, Ming Lei wrote:
> > But why does DMA segment size have to be >= PAGE_SIZE(4KB, 64KB)?
> 
> From the description of patch 5/8 of my patch series: "If the segment
> size is smaller than the page size there may be multiple segments per
> bvec even if a bvec only contains a single page." The current block
> layer implementation is based on the assumption that a single page
> fits in a single DMA segment. Please take a look at patch 5/8 of my
> patch series.

OK, I guess you agree it is one block layer constraint now, which
need to be relaxed for both big logical block size and >4k PAGE_SIZE.

Yes, your patch 5/8 is still needed.

> 
> > From the link, you have storage controllers with DMA segment size which
> > is less than 4K, which may never get supported by linux kernel.
> 
> As mentioned in the cover letter of that patch series, I came up with
> that patch series to support a DMA controller with max_segment_size of
> 4 KiB on a system with a PAGE_SIZE of 16 KiB.

Probably the conception of subpage need to avoid, because PAGE_SIZE is
config option, and not see strong reason to couple with fixed &
readable hardware properties with configurable kernel page size.


Thanks,
Ming


      parent reply	other threads:[~2025-01-06  1:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-02  1:56 [PATCH] block: make queue limits workable in case of 64K PAGE_SIZE Ming Lei
2025-01-02  2:30 ` Bart Van Assche
2025-01-02  2:49   ` Ming Lei
2025-01-02  3:46     ` Bart Van Assche
2025-01-03  2:01       ` Ming Lei
2025-01-03 22:12         ` Bart Van Assche
2025-01-04  1:47           ` Luis Chamberlain
2025-01-04  2:15             ` Bart Van Assche
2025-01-04  4:04               ` Luis Chamberlain
2025-01-04 22:30                 ` Bart Van Assche
2025-01-08 19:32                   ` Luis Chamberlain
2025-01-05  0:59                 ` Keith Busch
2025-01-08 19:12                   ` Luis Chamberlain
2025-01-06  1:20           ` Ming Lei [this message]

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=Z3svwejnonFmsY8q@fedora \
    --to=ming.lei@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=hch@lst.de \
    --cc=john.g.garry@oracle.com \
    --cc=linux-block@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=yi.zhang@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.