From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <keith.busch@intel.com>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
Bart Van Assche <bart.vanassche@wdc.com>,
Ming Lei <tom.leiming@gmail.com>
Subject: Re: [RFC PATCH] blk-mq: User defined HCTX CPU mapping
Date: Wed, 20 Jun 2018 11:08:05 +0200 [thread overview]
Message-ID: <20180620090805.GA4205@lst.de> (raw)
In-Reply-To: <20180618173206.19506-1-keith.busch@intel.com>
On Mon, Jun 18, 2018 at 11:32:06AM -0600, Keith Busch wrote:
> The default mapping of a cpu to a hardware context is often generally
> applicable, however a user may know of a more appropriate mapping for
> their specific access usage.
>
> This patch allows a user to define their own policy by making the mq hctx
> cpu_list writable. The usage allows a user to append a comma separated
> and/or range list of CPUs to a given hctx's tag set mapping to reassign
> what hctx a cpu may map.
>
> While the writable attribute exists under a specific request_queue, the
> settings will affect all request queues sharing the same tagset.
>
> The user defined setting is lost if the block device is removed and
> re-added, or if the driver re-runs the queue mapping.
We can't do this without driver opt-in. Managed interrupt rely on
the fact that we can't generate more interrupts once all cpus mapped
to the interrupt line have been offlined.
So what exactly is the use case? What drivers do you care about?
next prev parent reply other threads:[~2018-06-20 9:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-18 17:32 [RFC PATCH] blk-mq: User defined HCTX CPU mapping Keith Busch
2018-06-20 9:08 ` Christoph Hellwig [this message]
2018-06-20 14:49 ` Keith Busch
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=20180620090805.GA4205@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=bart.vanassche@wdc.com \
--cc=keith.busch@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=tom.leiming@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