linux-kernel - Re: [RFC]block: add a new flag to make request complete on submitted cpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091221091030.GF4489@kernel.dk>
Date:	Mon, 21 Dec 2009 10:10:30 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Shaohua Li <shaohua.li@...el.com>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [RFC]block: add a new flag to make request complete on
	submitted  cpu

On Mon, Dec 21 2009, Shaohua Li wrote:
> We already have a QUEUE_FLAG_SAME_COMP, which makes request complete
> on the first cpu of a mc/ht, but this isn't sufficient. In a system
> with fast block devices (intel SSD), it turns out the first cpu is
> bottlenect. Add a flag to make request complete on cpu where request
> is submitted. The flag implies QUEUE_FLAG_SAME_COMP. By default, it is off.

It was a lazy trick to avoid doing any round robin work in there.

> My test machine has two CPUs and 4 intel SSD. Without the new flag,
> the io thoughput is about 400m/s; with it, the thoughput is about 500m/s.

So I think we should just fix it, I still think the group logic makes
sense. But instead of always going for the first one, let it complete
locally if part of the group, if not send to specific submitter CPU.

-- 
Jens Axboe

--
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/