From: Vivek Goyal <vgoyal@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: axboe@kernel.dk, ctalbott@google.com, rni@google.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 06/12] blkcg: use q and plid instead of opaque void * for blkio_group association
Date: Thu, 19 Jan 2012 09:04:42 -0500 [thread overview]
Message-ID: <20120119140442.GA9582@redhat.com> (raw)
In-Reply-To: <1326935490-11827-7-git-send-email-tj@kernel.org>
On Wed, Jan 18, 2012 at 05:11:24PM -0800, Tejun Heo wrote:
> blkgio_group is association between a block cgroup and a queue for a
> given policy. Using opaque void * for association makes things
> confusing and hinders factoring of common code. Use request_queue *
> and, if necessary, policy id instead.
>
> This will help block cgroup API cleanup.
Using void* allowed one to pass any type of data pointer as key by the
client.
I think passing cfq_data or throtl_data as key is better than passing
request queue as key.
- During elevator exit, it looks like there will be a small window where
groups from both old elevator and new elevator will be present in blkcg
list. Given the fact that there can be only one active elevator at a
time, during cgroup removal call there is no way to reach a group's
cfqd. One can only retrieve request queue reliably and can't rely
on q->elevator->elevator_data.
So passing cfq_data as key provides more flexibility and allows
co-existence of two elevators more naturally without information loss.
[..]
> -static void cfq_unlink_blkio_group(void *key, struct blkio_group *blkg)
> +static void cfq_unlink_blkio_group(struct request_queue *q,
> + struct blkio_group *blkg)
> {
> - unsigned long flags;
> - struct cfq_data *cfqd = key;
> + struct cfq_data *cfqd = q->elevator->elevator_data;
> + unsigned long flags;
>
> - spin_lock_irqsave(cfqd->queue->queue_lock, flags);
> + spin_lock_irqsave(q->queue_lock, flags);
> cfq_destroy_cfqg(cfqd, cfqg_of_blkg(blkg));
> - spin_unlock_irqrestore(cfqd->queue->queue_lock, flags);
> + spin_unlock_irqrestore(q->queue_lock, flags);
I think this code will create problem where both old elevator group and
new elevator group is on blkcg list and upon cgroup removal one can not
rely that q->elevator->elevator_data will give us old elevator's cfqd.
Having said that, in practice we might never hit it as elevator init time
we only initialize and connect root group in blkcg list and one can not
delete root cgroup so above function is never called for root group.
But I think it is confusing so it is probably better to register cfq_data
or throtl_data as key instead of request queue.
Thanks
Vivek
next prev parent reply other threads:[~2012-01-19 14:04 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-19 1:11 [PATCHSET] blkcg: kill policy node and blkg->dev Tejun Heo
2012-01-19 1:11 ` [PATCH 01/12] blkcg: obtaining blkg should be enclosed inside rcu_read_lock() Tejun Heo
2012-01-19 10:07 ` Vivek Goyal
2012-01-19 15:39 ` Tejun Heo
2012-01-19 15:54 ` Vivek Goyal
2012-01-19 15:58 ` Tejun Heo
2012-01-19 1:11 ` [PATCH 02/12] cfq: don't register propio policy if !CONFIG_CFQ_GROUP_IOSCHED Tejun Heo
2012-01-19 10:11 ` Vivek Goyal
2012-01-19 1:11 ` [PATCH 03/12] elevator: clear auxiliary data earlier during elevator switch Tejun Heo
2012-01-19 1:11 ` [PATCH 04/12] elevator: make elevator_init_fn() return 0/-errno Tejun Heo
2012-01-19 11:11 ` Vivek Goyal
2012-01-19 15:44 ` Tejun Heo
2012-01-19 1:11 ` [PATCH 05/12] blkcg: update blkg get functions take blkio_cgroup as parameter Tejun Heo
2012-01-19 11:21 ` Vivek Goyal
2012-01-19 15:45 ` Tejun Heo
2012-01-19 1:11 ` [PATCH 06/12] blkcg: use q and plid instead of opaque void * for blkio_group association Tejun Heo
2012-01-19 14:04 ` Vivek Goyal [this message]
2012-01-19 15:55 ` Tejun Heo
2012-01-19 16:16 ` Vivek Goyal
2012-01-19 16:25 ` Tejun Heo
2012-01-19 16:42 ` Tejun Heo
2012-01-19 1:11 ` [PATCH 07/12] blkcg: add blkio_policy[] array and allow one policy per policy ID Tejun Heo
2012-01-19 1:11 ` [PATCH 08/12] blkcg: use the usual get blkg path for root blkio_group Tejun Heo
2012-01-19 14:41 ` Vivek Goyal
2012-01-19 16:17 ` Tejun Heo
2012-01-19 1:11 ` [PATCH 09/12] blkcg: factor out blkio_group creation Tejun Heo
2012-01-19 1:11 ` [PATCH 10/12] blkcg: don't allow or retain configuration of missing devices Tejun Heo
2012-01-19 1:11 ` [PATCH 11/12] blkcg: kill blkio_policy_node Tejun Heo
2012-01-19 20:32 ` Vivek Goyal
2012-01-19 22:03 ` Tejun Heo
2012-01-19 22:30 ` Vivek Goyal
2012-01-19 1:11 ` [PATCH 12/12] blkcg: kill the mind-bending blkg->dev Tejun Heo
2012-01-19 15:49 ` Vivek Goyal
2012-01-19 16:30 ` Tejun Heo
2012-01-19 16:46 ` Vivek Goyal
2012-01-19 1:18 ` [PATCHSET] blkcg: kill policy node and blkg->dev Tejun Heo
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=20120119140442.GA9582@redhat.com \
--to=vgoyal@redhat.com \
--cc=axboe@kernel.dk \
--cc=ctalbott@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rni@google.com \
--cc=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;
as well as URLs for NNTP newsgroup(s).