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] [day] [month] [year] [list]

Date:	Wed, 14 Sep 2011 14:04:23 +0800
From:	Shaohua Li <shaohua.li@...el.com>
To:	Tejun Heo <htejun@...il.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

On Tue, 2011-09-13 at 15:46 +0800, Tejun Heo wrote:
> 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?
Just found request_queue->queue_head list usually has only one entry,
because drive only takes one extra request from elevator. so either
dispatch_sort() or dispatch_add_tail() has no difference.

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/