From: Jens Axboe <jaxboe@fusionio.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Jerome Marchand <jmarchan@redhat.com>,
Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] Don't merge different partition's IOs
Date: Tue, 14 Dec 2010 21:25:16 +0100 [thread overview]
Message-ID: <4D07D2AC.6000500@fusionio.com> (raw)
In-Reply-To: <20101210165553.GE31737@redhat.com>
On 2010-12-10 17:55, Vivek Goyal wrote:
> On Fri, Dec 10, 2010 at 05:12:04PM +0100, Jerome Marchand wrote:
>> On 12/08/2010 03:46 PM, Jens Axboe wrote:
>>>
>>> No, that's not it at all. What I mean (and what was reverted) was
>>> caching the partition lookup, and using that for the stats. The problem
>>> with that approach turned out to be the elevator queiscing logic not
>>> being fully correct. One easier way to fix that would be to reference
>>> count the part stats, instead of having to drain the queue.
>>>
>>
>> The partition is already deleted in a rcu callback function. If I
>> understand RCU correctly, we just need to use rcu_dereference() each time
>> we use rq->part. Something like the following *untested* patch.
>
> Jerome,
>
> I don't think that rcu_dereference() is going to solve the problem. The
> partition table will be freed as soon as one rcu period is over. So to
> make sure partition table is not freed one has to be holding
> rcu_read_lock(). It is not a good idea to keep rcu period going till
> request finishes so a better idea will to to reference count it.
Exactly. The only change you would do to partition handling is ensure
that each io grabs a reference to it and drops it at the end. You need
not even do that in the core bits outside each IO, we just need to
ensure that the partition struct persists in memory even if it is no
longer the valid partition table. The rcu call to free the memory would
happen when the ref drops to zero.
What Vivek says it completely correct, and rcu_dereference() would only
help if you also had rcu_read_lock() over each IO. That is not feasible
at all.
--
Jens Axboe
next prev parent reply other threads:[~2010-12-14 20:47 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-06 9:44 [PATCH 1/2] Don't merge different partition's IOs Yasuaki Ishimatsu
2010-12-06 16:08 ` Linus Torvalds
2010-12-07 7:18 ` Satoru Takeuchi
2010-12-07 18:39 ` Vivek Goyal
2010-12-08 7:33 ` Jens Axboe
2010-12-08 7:59 ` Satoru Takeuchi
2010-12-08 8:06 ` Jens Axboe
2010-12-08 8:11 ` Satoru Takeuchi
2010-12-08 14:46 ` Jens Axboe
2010-12-08 15:51 ` Vivek Goyal
2010-12-08 15:58 ` Vivek Goyal
2010-12-10 11:22 ` Jerome Marchand
2010-12-10 16:12 ` Jerome Marchand
2010-12-10 16:55 ` Vivek Goyal
2010-12-14 20:25 ` Jens Axboe [this message]
2010-12-17 13:42 ` [PATCH] block: fix accounting bug on cross partition merges Jerome Marchand
2010-12-17 19:06 ` Jens Axboe
2010-12-17 22:32 ` Vivek Goyal
2010-12-23 15:10 ` Jerome Marchand
2010-12-23 15:39 ` Vivek Goyal
2010-12-23 17:04 ` Jerome Marchand
2010-12-24 19:29 ` Vivek Goyal
2011-01-04 15:52 ` [PATCH 1/2] kref: add kref_test_and_get Jerome Marchand
2011-01-04 15:55 ` [PATCH 2/2] block: fix accounting bug on cross partition merges Jerome Marchand
2011-01-04 21:00 ` Greg KH
2011-01-05 13:51 ` Jerome Marchand
2011-01-05 16:00 ` Greg KH
2011-01-05 16:19 ` Jerome Marchand
2011-01-05 16:27 ` Greg KH
2011-01-05 13:55 ` Jens Axboe
2011-01-05 15:58 ` Greg KH
2011-01-05 18:46 ` Jens Axboe
2011-01-05 20:08 ` Greg KH
2011-01-05 21:38 ` Jens Axboe
2011-01-05 22:16 ` Greg KH
2011-01-06 9:46 ` Jens Axboe
2011-01-05 14:00 ` Jens Axboe
2011-01-05 14:09 ` Jerome Marchand
2011-01-05 14:17 ` Jens Axboe
2011-01-04 16:05 ` [PATCH 1/2] kref: add kref_test_and_get Eric Dumazet
2011-01-05 15:02 ` [PATCH 1/2 v2] " Jerome Marchand
2011-01-05 15:43 ` Alexey Dobriyan
2011-01-05 15:57 ` Greg KH
2011-01-05 15:56 ` Greg KH
2011-01-04 20:57 ` [PATCH 1/2] " Greg KH
2011-01-05 13:35 ` Jerome Marchand
2011-01-05 15:55 ` Greg KH
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=4D07D2AC.6000500@fusionio.com \
--to=jaxboe@fusionio.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=jmarchan@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=takeuchi_satoru@jp.fujitsu.com \
--cc=torvalds@linux-foundation.org \
--cc=vgoyal@redhat.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