All of lore.kernel.org
 help / color / mirror / Atom feed
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 17:01:52 -0600	[thread overview]
Message-ID: <5702F260.5010404@windriver.com> (raw)
In-Reply-To: <1459808966.10124.11.camel@haakon3.risingtidesystems.com>

On 04/04/2016 04:29 PM, Nicholas A. Bellinger wrote:
> On Mon, 2016-04-04 at 09:20 -0600, Chris Friesen wrote:
>> 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?
>>
>
> block cgroups does I/O ratelimiting at struct block_device level.
>
> Eg: The process cgroup (which AFAICT is what your thinking about) is
> separate from block cgroups, and doesn't need to be explicitly enabled
> in order for block cgroup to function.
>

I'm still confused.

I'm not trying to globally throttle IO on a particular block device.  I'm trying 
to control how much IO the iSCSI target in the kernel is allowed to drive on a 
particular block device.

The goal is to ensure that the iSCSI target does not consume all of the 
available bandwidth for a particular block device.  I want to ensure that some 
of the bandwidth for that device is available to other processes on the host 
(for management purposes) rather than being consumed by a greedy iSCSI initiator.

In an ideal world I would like a set of rules that say things like:
1) if there is contention, ensure that the host is guaranteed X percent of the 
available /dev/sdb IOPS
2) if there is contention, do not allow the iSCSI target traffic to consume more 
than Y percent of /dev/sdb's write traffic

Chris

  reply	other threads:[~2016-04-04 23:02 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
2016-04-04 22:29               ` Nicholas A. Bellinger
2016-04-04 23:01                 ` Chris Friesen [this message]
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=5702F260.5010404@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.