linux-kernel - Re: [PATCH block:for-3.3/core] cfq: merged request shouldn't jump to a different cfqq

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]

Date:	Thu, 5 Jan 2012 20:40:06 -0800
From:	Tejun Heo <tj@...nel.org>
To:	Shaohua Li <shaohua.li@...el.com>
Cc:	Jens Axboe <axboe@...nel.dk>, Hugh Dickins <hughd@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	linux-scsi@...r.kernel.org, linux-ide@...r.kernel.org,
	x86@...nel.org
Subject: Re: [PATCH block:for-3.3/core] cfq: merged request shouldn't jump to
 a different cfqq

Hello,

On Thu, Jan 5, 2012 at 8:15 PM, Shaohua Li <shaohua.li@...el.com> wrote:
> don't know. I don't think a tweak for merge impacts isolation so much.
> For rotate disk, request size hasn't impact to request cost, so this
> doesn't impact isolation. Even for ssd, big size request is more
> efficient to dispatch. And we already have breakage of fairness for SSD,
> such as no idle.

I'm not saying they shouldn't be merged but the decision should be
elevator's. Block core shouldn't decide it for the elevator. So,
whether cross cfqq merge is a good idea or not is mostly irrelevant in
this thread.

Thanks.

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