From: Andrew Morton <akpm@osdl.org>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: per-cpu blk_plug_list
Date: Mon, 1 Mar 2004 14:17:28 -0800 [thread overview]
Message-ID: <20040301141728.71e49546.akpm@osdl.org> (raw)
In-Reply-To: <B05667366EE6204181EABE9C1B1C0EB501F2AB4C@scsmsx401.sc.intel.com>
"Chen, Kenneth W" <kenneth.w.chen@intel.com> wrote:
>
> We were surprised to find global lock in I/O path still exists on 2.6
> kernel.
Well I'm surprised that nobody has complained about it yet ;)
Disks are slow. 100 requests per second, perhaps. So a single lock is
generally OK until you have a vast number of disks and lots of
contention-prone CPUs.
Yes, we should fix this.
> blk_plug_list/blk_plug_lock manages plug/unplug action. When you have
> lots of cpu simultaneously submits I/O, there are lots of movement with
> the device queue on and off that global list. Our measurement showed
> that blk_plug_lock contention prevents linux-2.6.3 kernel to scale pass
> beyond 40 thousand I/O per second in the I/O submit path.
Looking at the guts of your patch:
/*
* blk_run_queues_cpu - fire all plugged queues on this cpu
*/
#define blk_plug_entry(entry) list_entry((entry), request_queue_t, plug_list)
void blk_run_queues_cpu(int cpu)
{
struct blk_plug_struct * cur_blk_plug = &blk_plug_array[cpu];
struct list_head * head = &cur_blk_plug->blk_plug_head;
spinlock_t *lock = &cur_blk_plug->blk_plug_lock;
spin_lock_irq(lock);
while (!list_empty(head)) {
request_queue_t *q = blk_plug_entry(head->next);
spin_unlock_irq(lock);
q->unplug_fn(q);
spin_lock_irq(lock);
}
spin_unlock_irq(lock);
}
void blk_run_queues(void)
{
int i;
for_each_cpu(i)
blk_run_queues_cpu(i);
}
How on earth do you know that when direct-io calls blk_run_queues_cpu(), it
is still running on the cpu which initially plugged the queue(s)?
And your patch might have made the much-more-frequently-called
blk_run_queues() more expensive.
There are minor issues with lack of preemption safety and not using the
percpu data infrastructure, but they can wait.
You haven't told us how many disks are in use? At 100k IO's per second it
would be 500 to 1000 disks, yes?
I assume you tried it, but does this help?
diff -puN drivers/block/ll_rw_blk.c~a drivers/block/ll_rw_blk.c
--- 25/drivers/block/ll_rw_blk.c~a Mon Mar 1 13:52:37 2004
+++ 25-akpm/drivers/block/ll_rw_blk.c Mon Mar 1 13:52:45 2004
@@ -1251,6 +1251,9 @@ void blk_run_queues(void)
{
LIST_HEAD(local_plug_list);
+ if (list_empty(&blk_plug_list))
+ return;
+
spin_lock_irq(&blk_plug_lock);
/*
_
next prev parent reply other threads:[~2004-03-01 22:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-01 21:18 per-cpu blk_plug_list Chen, Kenneth W
2004-03-01 22:06 ` Jens Axboe
2004-03-01 22:17 ` Andrew Morton [this message]
2004-03-01 22:31 ` Andrew Morton
[not found] ` <B05667366EE6204181EABE9C1B1C0EB501F2AB4C@scsmsx401.sc.intel.com.suse.lists.linux.kernel>
2004-03-01 22:36 ` Andi Kleen
2004-03-01 22:39 ` per-cpu blk_plug_list II Andi Kleen
2004-03-03 3:44 ` per-cpu blk_plug_list Jesse Barnes
2004-03-03 3:55 ` Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2004-03-03 4:20 Chen, Kenneth W
2004-03-03 4:20 ` Chen, Kenneth W
2004-03-03 5:13 ` Andrew Morton
2004-03-03 5:13 ` Andrew Morton
2004-03-03 9:45 ` Miquel van Smoorenburg
2004-03-03 9:54 ` Andrew Morton
2004-03-03 16:24 ` Miquel van Smoorenburg
2004-03-03 22:37 ` Miquel van Smoorenburg
2004-03-01 22:28 Chen, Kenneth W
2004-03-01 22:14 Chen, Kenneth W
[not found] <cistron.B05667366EE6204181EABE9C1B1C0EB50211E5C8@scsmsx401.sc.intel.com>
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=20040301141728.71e49546.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=kenneth.w.chen@intel.com \
--cc=linux-kernel@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.