linux-kernel - Re: [PATCH] cfq: Fix starvation of async writes in presence of heavy sync workload

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]

Message-ID: <20110620223321.GA10523@redhat.com>
Date:	Mon, 20 Jun 2011 18:33:21 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Justin TerAvest <teravest@...gle.com>
Cc:	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Jens Axboe <axboe@...nel.dk>, Tao Ma <tm@....ma>
Subject: Re: [PATCH] cfq: Fix starvation of async writes in presence of heavy
 sync workload

On Mon, Jun 20, 2011 at 03:16:48PM -0700, Justin TerAvest wrote:

[..]
> How do we establish what's acceptable? My complaint is that it's not
> obvious what tradeoffs to make in the I/O scheduler.
> 

I think it should be driven with real workloads and some common
sense. Easily reproducible complete starvation of async requests
sounds bad enough that it needs fixing. 

> >
> >> This makes the preemption logic slightly harder to understand, and I'm
> >> concerned we'll keep making little adjustments like this to the
> >> scheduler.
> >
> > If you have other ideas for handling this, we can definitely give
> > it a try.
> 
> I haven't written out a case to prove it, but it seems like other
> preemption logic (like the cfq_rq_close() case) could also cause some
> requests to be starved indefinitely.

If we can easily reproduce this starvation may be that also needs
fixing.

> 
> I think if we want to make stronger guarantees about request
> starvation, we might have to rethink how preemption works.

What's your proposal? cpu scheduler like only class based preemption
is not going to work for the simple reason that writes come in big
sizes without any dependencies and reads can come in small sizes
one at a time because these are dependent reads.

So are you saying that write starvation is not a real problem or you
are suggesting that overall you are not happy with preemption logic
and want more changes in there.

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