Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: tj@kernel.org (Tejun Heo)
Subject: [PATCH v3 1/5] block: add weighted round robin for blkcgroup
Date: Thu, 18 Jul 2019 06:59:16 -0700	[thread overview]
Message-ID: <20190718135916.GC696309@devbig004.ftw2.facebook.com> (raw)
In-Reply-To: <1333161d2c64dbe93f9dcd0814ffaf6d00216d58.1561385989.git.zhangweiping@didiglobal.com>

Hello, Weiping.

On Mon, Jun 24, 2019@10:28:51PM +0800, Weiping Zhang wrote:
> +static const char *blk_wrr_name[BLK_WRR_COUNT] = {
> +	[BLK_WRR_NONE]		= "none",
> +	[BLK_WRR_LOW]		= "low",
> +	[BLK_WRR_MEDIUM]	= "medium",
> +	[BLK_WRR_HIGH]		= "high",
> +	[BLK_WRR_URGENT]	= "urgent",
> +};

cgroup controllers must be fully hierarchical which the proposed
implementation isn't.  While it can be made hierarchical, there's only
so much one can do if there are only five priority levels.

Can you please take a look at the following?

  http://lkml.kernel.org/r/20190710205128.1316483-1-tj at kernel.org

In comparison, I'm having a bit of hard time seeing the benefits of
this approach.  In addition to the finite level limitation, the actual
WRR behavior would be device dependent and what each level means is
likely to fluctuate depending on the workload and device model.

I wonder whether WRR is something more valuable to help internal queue
management rather than being exposed to userspace directly.

Thanks.

-- 
tejun

  reply	other threads:[~2019-07-18 13:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1561385989.git.zhangweiping@didiglobal.com>
2019-06-24 14:28 ` [PATCH v3 1/5] block: add weighted round robin for blkcgroup Weiping Zhang
2019-07-18 13:59   ` Tejun Heo [this message]
2019-07-23 14:29     ` Weiping Zhang
2019-06-24 14:29 ` [PATCH v3 2/5] nvme: add get_ams for nvme_ctrl_ops Weiping Zhang
2019-06-24 20:12   ` Minwoo Im
2019-06-25 14:46     ` Weiping Zhang
2019-06-24 14:29 ` [PATCH v3 3/5] nvme-pci: rename module parameter write_queues to read_queues Weiping Zhang
2019-06-24 20:04   ` Minwoo Im
2019-06-25 14:48     ` Weiping Zhang
2019-06-26 20:27       ` Minwoo Im
2019-07-14 11:36   ` Minwoo Im
2019-06-24 14:29 ` [PATCH v3 4/5] genirq/affinity: allow driver's discontigous affinity set Weiping Zhang
2019-06-24 15:42   ` Thomas Gleixner
2019-06-25  2:14     ` Ming Lei
2019-06-25  6:13       ` Thomas Gleixner
2019-06-25 14:55         ` Weiping Zhang
2019-06-24 14:29 ` [PATCH v3 5/5] nvme: add support weighted round robin queue Weiping Zhang
2019-06-24 20:21   ` Minwoo Im
2019-06-25 15:06     ` Weiping Zhang
2019-06-27 10:37   ` Minwoo Im
2019-06-27 11:03     ` Christoph Hellwig
2019-06-28 15:57       ` Weiping Zhang
2019-07-10 14:20         ` Weiping Zhang
2019-07-29 10:22           ` Weiping Zhang

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=20190718135916.GC696309@devbig004.ftw2.facebook.com \
    --to=tj@kernel.org \
    /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