linux-kernel - Re: [RFC]block: add flush request at head

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:	Sat, 23 Apr 2011 00:57:04 +0200
From:	Tejun Heo <htejun@...il.com>
To:	Shaohua Li <shaohua.li@...el.com>
Cc:	Jens Axboe <jaxboe@...ionio.com>,
	lkml <linux-kernel@...r.kernel.org>,
	"Shi, Alex" <alex.shi@...el.com>,
	"Chen, Tim C" <tim.c.chen@...el.com>
Subject: Re: [RFC]block: add flush request at head

Hello,

On Mon, Apr 18, 2011 at 04:25:57PM +0800, Shaohua Li wrote:
> then why requeue adds request at head? we could have the similar issue.

SCSI doesn't seem to do it anymore but it used to cache scmd at
rq->special over requeues so that it doesn't have to re-initialize
requests across requeues, which means that unprepped request getting
ahead of requeued ones may lead to deadlock due to resource
starvation, so that's why requeue uses front queueing.

The code changed over time and the above requirement might not be
necessary at this point.  I don't know.  However, block layer doesn't
have any method to enforce that requests can't hold any extra resource
on requeue and having such difficult to trigger deadlock condition
dormant is scary.

What kind of benchmarking are we talking about on which kernel?
blk-flush support has been revamped twice recently.  2.6.38 stripped
out the block layer barrier thing and then it got re-reimplemented for
2.6.39 to support advanced flush merging.  If the regression (for
which benchmark btw?) was visible on the older reimplementation, I'd
really like to know how it behaves on 2.6.39-rcX.

If the problem is localized to 2.6.38, oh well, too bad, but I don't
think we care too much.  If some distro is basing their kernel on
2.6.38 and the flush regression is hurting them, backporting the new
implementation from 2.6.39 shouldn't be too difficult after all.  The
reimplementation was almost self-contained.

If the regression affects 2.6.39 implementation too, eh well, we need
to think of something, but I'd really like to know what kind of
workload we're talking about.

> I'll look at this. Optimizing this one should fix the regression too. On
> the other hand, adding flush request at head if it just follows a flush
> still has its advantage, because drive cache is already flushed out.

New implementation wouldn't issue two flushes back to back like that,
it doesn't make any sense to begin with.  Again, what have you been
testing and how?

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/