linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Hannes Reinecke <hare@suse.de>
Cc: Arnd Bergmann <arnd@arndb.de>,
	"(Exiting) Baolin Wang" <baolin.wang@linaro.org>,
	Baolin Wang <baolin.wang7@gmail.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	asutoshd@codeaurora.org, Orson Zhai <orsonzhai@gmail.com>,
	Lyra Zhang <zhang.lyra@gmail.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Hannes Reinecke <hare@suse.com>,
	linux-block <linux-block@vger.kernel.org>,
	Paolo Valente <paolo.valente@linaro.org>
Subject: Re: [PATCH v6 0/4] Add MMC software queue support
Date: Wed, 27 Nov 2019 01:00:23 -0800	[thread overview]
Message-ID: <20191127090023.GA23040@infradead.org> (raw)
In-Reply-To: <f88856aa-9175-2a93-3747-c98215cb79c3@suse.de>

On Tue, Nov 26, 2019 at 12:17:15PM +0100, Hannes Reinecke wrote:
> Aligning with the 'traditional' linux way for partition handling is
> definitely the way to go IMO; otherwise you'll end up having to worry
> about resource allocation between distinct queues (like you have to do
> now), and will be having a hard time trying to map it properly to the
> underlying hardware abstraction in blk-mq.

Sorry, but this is complete bullshit.  Except for the very unfortunate
name MMC partitions have nothing to do with partitions.  They are a
concept roughly equivalent to SCSI logical units and nvme namespace,
just with a pretty idiotic design decision that only allows I/O to one
of them at a time.  The block layer way to deal with them is to use
a shared tagset for multiple request queues, which doesn't use up a
whole lot of resources.  The only hard part is the draining when
switching between partitions, and there is no really nice way to
deal with that.   If requests are batched enough we could just drain
and switch every time an other partition access comes in.  Especially
so if people only use partitions for boot partitions and other rarely
used areas.  If that doesn't work out we'll just have to reject other
partition access and then use a timer and/or counter to eventually
switch and provide basic fairness.

  parent reply	other threads:[~2019-11-27  9:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-11  7:33 [PATCH v6 0/4] Add MMC software queue support Baolin Wang
2019-11-11  7:33 ` [PATCH v6 1/4] mmc: Add MMC host " Baolin Wang
2019-11-11  7:33 ` [PATCH v6 2/4] mmc: host: sdhci: Add request_done ops for struct sdhci_ops Baolin Wang
2019-11-11  7:33 ` [PATCH v6 3/4] mmc: host: sdhci-sprd: Add software queue support Baolin Wang
2019-11-11  7:34 ` [PATCH v6 4/4] mmc: host: sdhci: Add a variable to defer to complete requests if needed Baolin Wang
2019-11-11  7:44   ` Adrian Hunter
2019-11-11  7:57     ` Baolin Wang
2019-11-11  9:28 ` [PATCH v6 0/4] Add MMC software queue support Arnd Bergmann
2019-11-11 12:58   ` Baolin Wang
2019-11-11 16:59     ` Arnd Bergmann
2019-11-12  8:48       ` Baolin Wang
2019-11-18 10:04         ` (Exiting) Baolin Wang
2019-11-22  9:50           ` Arnd Bergmann
2019-11-22 13:19             ` Linus Walleij
2019-11-22 13:49               ` Arnd Bergmann
2019-11-26  7:40             ` Paolo Valente
2019-11-26  9:54               ` Arnd Bergmann
2019-11-26 11:17             ` Hannes Reinecke
2019-11-27  7:49               ` Baolin Wang
2019-11-27  9:00               ` Christoph Hellwig [this message]
2019-11-27 12:01                 ` Arnd Bergmann
2019-12-10 15:17                   ` Ulf Hansson
2019-11-28 12:15                 ` Martin K. Petersen
2019-11-28 15:54                   ` 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=20191127090023.GA23040@infradead.org \
    --to=hch@infradead.org \
    --cc=adrian.hunter@intel.com \
    --cc=arnd@arndb.de \
    --cc=asutoshd@codeaurora.org \
    --cc=baolin.wang7@gmail.com \
    --cc=baolin.wang@linaro.org \
    --cc=hare@suse.com \
    --cc=hare@suse.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=orsonzhai@gmail.com \
    --cc=paolo.valente@linaro.org \
    --cc=ulf.hansson@linaro.org \
    --cc=vincent.guittot@linaro.org \
    --cc=zhang.lyra@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).