linux-kernel - Re: [PATCH/RFC 0/4] cfq: implement merging and breaking up of cfq

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:	Mon, 26 Oct 2009 14:34:22 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Jeff Moyer <jmoyer@...hat.com>
Cc:	Corrado Zoccolo <czoccolo@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH/RFC 0/4] cfq: implement merging and breaking up of
	cfq_queues

On Mon, Oct 26 2009, Jeff Moyer wrote:
> Corrado Zoccolo <czoccolo@...il.com> writes:
> 
> > Hi Jeff,
> > this series looks good.
> 
> Hi, Corrado.  Thanks again for the review!
> 
> > I like in particular the fact that you move seekiness detection in the cfqq.
> > This can help with processes that issue sequential reads and seeky
> > writes, or vice versa.
> > Probably, also the think time could be made per-cfqq, so that the
> > decision whether we should idle for a given cfqq is more precise.
> 
> I'll have to think about that one.  It would be good to know Jens'
> opinion on the matter, too.

Your implementation looks fine, as usual I'm mostly worried about
performance impact and suitability (I hate having to work around
issues). But the win is so large in some cases that we should just go
ahead and merge it for .33, so I'll queue it up.

It would be nice to fix the in-kernel problem with NFS, since that is
doable.

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