[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANejiEVzs=pUhQSTvUppkDcc2TNZyfohBRLygW5zFmXyk5A-xQ@mail.gmail.com>
Date: Tue, 7 Feb 2012 08:31:22 +0800
From: Shaohua Li <shaohua.li@...el.com>
To: Tejun Heo <tj@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Vivek Goyal <vgoyal@...hat.com>, Jens Axboe <axboe@...nel.dk>,
lkml <linux-kernel@...r.kernel.org>,
Knut Petersen <Knut_Petersen@...nline.de>, mroos@...ux.ee
Subject: Re: [patch]block: fix ioc locking warning
2012/2/7 Tejun Heo <tj@...nel.org>:
> On Mon, Feb 06, 2012 at 09:27:06AM -0800, Tejun Heo wrote:
>> It's one wq scheduling on exit for any task which has issued an IO. I
>> don't think it would matter except for task fork/exit microbenchs (or
>> workloads which approximate to that). I'll get some measurements and
>> strip the optimization if it doesn't really show up.
>
> I'm still playing with test methods and getting numbers but the
> following is the simplified one of the three setups I'm playing with -
> the current one, simplified and no optimization. There *seems* to be
> appreciable performance degradation on fork/exit w/ ioc microbenchs so
> I'm likely to go with the following. I'll post when I know more.
Hi,
Since you are talking about performance, one of our microbenchmark (swap)
shows a regression. Alex bisect it to be b2efa05265d62bc2, which is related to
the ioc change. A little strange to me, don't expect such change can cause
performance issue. I haven't double check the issue, but if you have
ideas, please
let me know.
Thanks,
Shaohua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists