From: "Jianpeng Ma" <majianpeng@gmail.com>
To: shli <shli@kernel.org>
Cc: axboe <axboe@kernel.dk>, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Re: [RFC PATCH] block:Fix some problems about handling plug in blk_queue_bio().
Date: Wed, 8 Aug 2012 13:35:35 +0800 [thread overview]
Message-ID: <201208081335333287528@gmail.com> (raw)
In-Reply-To: CANejiEXdHaqtXuR47QRimRNcvjxtUn8__7MK5XwW2t658hz=3g@mail.gmail.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 1990 bytes --]
On 2012-08-08 11:06 Shaohua Li <shli@kernel.org> Wrote:
>2012/8/8 Jianpeng Ma <majianpeng@gmail.com>:
>> I think there are three problems about handling plug in blk_queue_bio():
>> 1:if request_count >= BLK_MAX_REQUEST_COUNT, avoid unnecessary plug->should_sort judge.
>this makes sense, though not a big deal, nice to fix it.
Thanks
>
>> 2:Only two device can trace plug.
>I didn't get the point, can you have more details?
>>if (plug) {
>> /*
>> * If this is the first request added after a plug, fire
>> * of a plug trace. If others have been added before, check
>> * if we have multiple devices in this plug. If so, make a
>> * note to sort the list before dispatch.
>> */
>> if (list_empty(&plug->list))
>> trace_block_plug(q);
>> else {
>> if (!plug->should_sort) {
>> struct request *__rq;
>> __rq = list_entry_rq(plug->list.prev);
>> if (__rq->q != q)
>> plug->should_sort = 1;
>> }
>> if (request_count >= BLK_MAX_REQUEST_COUNT) {
>> blk_flush_plug_list(plug, false);
>> trace_block_plug(q);
The code only trace two point;
A: list_empty(&plug->list)
B: request_count >= BLK_MAX_REQUEST_COUNT). it's the same like A which plug->list is empty.
Suppose:
1;reqA-deviceA firstly come, it will call trace_block_plug because the list_empty(plug->list) is true.
2:reqB-deviceB comed, attempt_plug_merge will failed because not deviceB-request-queue.But it'll not to call trace_block_plug.
But call blk_flush_plug_list,it will trace_block_unplug all request_queue.
>
>> 3:When exec blk_flush_plug_list,it use list_sort which has
>> O(nlog(n)) complexity. When insert and sort, it only O(n) complexity.
>but now you do the list iterator for every request, so it's O(n*n)?
>The plug list is unlikely too long, so I didn't worry about the time
>spending on list sort.
Sorry, it's my fault.ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
next prev parent reply other threads:[~2012-08-08 5:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-08 2:05 [RFC PATCH] block:Fix some problems about handling plug in blk_queue_bio() Jianpeng Ma
2012-08-08 3:06 ` Shaohua Li
2012-08-08 5:35 ` Jianpeng Ma [this message]
2012-08-09 8:50 ` Shaohua Li
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=201208081335333287528@gmail.com \
--to=majianpeng@gmail.com \
--cc=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=shli@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.