From: Chris Friesen <chris.friesen@windriver.com>
To: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-scsi@vger.kernel.org, target-devel@vger.kernel.org
Subject: Re: QoS for iSCSI target?
Date: Mon, 4 Apr 2016 09:20:33 -0600 [thread overview]
Message-ID: <57028641.5000100@windriver.com> (raw)
In-Reply-To: <1459646152.13184.26.camel@haakon3.risingtidesystems.com>
On 04/02/2016 07:15 PM, Nicholas A. Bellinger wrote:
> On Fri, 2016-04-01 at 12:35 -0600, Chris Friesen wrote:
>>>> On a slightly different note, is there any way to throttle or limit the overall
>>>> bandwidth consumed by the iSCSI target in the kernel? I'd like to ensure that
>>>> the iSCSI traffic doesn't completely swamp the host accesses to the same block
>>>> device.
>>>>
>>>> I suppose I could do networking-based traffic shaping, but are there any
>>>> controls in the block IO subsystem?
>>>>
>>>
>>> On a individual block_device backend basis, block cgroups is the
>>> preferred method for doing this.
>>>
>>> Note that any rate limiting imposed by block cgroups is subject to the
>>> current se_node_acl->queue_depth enforced across all LUNs within a given
>>> iscsi session.
>>
>>
>> How would I use cgroups with the kernel iSCSI target? Is there a set of kernel
>> threads dedicated to the iSCSI target that I can assign to a particular group?
>>
>
> block cgroups can set I/O throttling (bandwidth + IOPs) limits for any
> normal struct block_device.
>
> These values are configured via blkio.throttle.* resource class, and the
> limits are imposed independently of the block_device's association with
> target_core_mod backend driver export. Namely:
>
> blkio.throttle.write_iops_device
> blkio.throttle.read_iops_device
> blkio.throttle.write_bps_device
> blkio.throttle.read_bdp_device
>
> Some examples using these values, plus more blkio.* info is here:
> http://events.linuxfoundation.org/sites/events/files/slides/cgroups_0.pdf.
>
I understand how to set up the cgroups, but don't I need to ensure that the IO
operations happen in the context of a particular cgroup? If so, how do I ensure
that the in-kernel iSCSI target traffic happens in the context of the specified
group? Are there a set of kernel threads dedicated to processing iSCSI requests?
Chris
next prev parent reply other threads:[~2016-04-04 15:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 22:24 QoS for iSCSI target? Chris Friesen
2016-03-11 7:30 ` Christoph Hellwig
2016-03-11 7:45 ` Nicholas A. Bellinger
2016-03-16 16:48 ` Chris Friesen
2016-03-31 7:05 ` Nicholas A. Bellinger
2016-04-01 18:35 ` Chris Friesen
2016-04-03 1:15 ` Nicholas A. Bellinger
2016-04-04 15:20 ` Chris Friesen [this message]
2016-04-04 22:29 ` Nicholas A. Bellinger
2016-04-04 23:01 ` Chris Friesen
2016-04-05 0:25 ` Nicholas A. Bellinger
2016-04-05 14:22 ` Chris Friesen
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=57028641.5000100@windriver.com \
--to=chris.friesen@windriver.com \
--cc=hch@infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=nab@linux-iscsi.org \
--cc=target-devel@vger.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 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.