linux-kernel - Re: [RFC]block: don't mark flush request as SOFTBARRIER

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:	Tue, 13 Sep 2011 16:46:53 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Shaohua Li <shaohua.li@...el.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Jens Axboe <jaxboe@...ionio.com>,
	Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [RFC]block: don't mark flush request as SOFTBARRIER

Hello, Shaohua.

On Tue, Sep 13, 2011 at 09:04:01AM +0800, Shaohua Li wrote:
> we do the flush first and then dispatch the data. The flush is
> already delayed a lot, so if latency is a problem, we already saw
> it.

I don't necessarily agree with the above.  We don't induce any extra
latency for flushes which don't overlap.

> Why not just remove SOFTBARRIER and use elv_dispatch_sort() for
> flush data so drive can better arrange requests?

Maybe, I don't know.  Elevator sorting on writes is likely to be much
less important to begin with.  Combined with the fact that sorting
flush data would require more writes to be flushed by the following
flush, I don't think it would be clear which way would be better.  If
it can be shown that sorting flush data is better, why not?

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/