Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756203Ab1FTWd3 (ORCPT ); Mon, 20 Jun 2011 18:33:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42428 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755338Ab1FTWd1 (ORCPT ); Mon, 20 Jun 2011 18:33:27 -0400 Date: Mon, 20 Jun 2011 18:33:21 -0400 From: Vivek Goyal To: Justin TerAvest Cc: linux kernel mailing list , Jens Axboe , Tao Ma Subject: Re: [PATCH] cfq: Fix starvation of async writes in presence of heavy sync workload Message-ID: <20110620223321.GA10523@redhat.com> References: <20110620141631.GA4749@redhat.com> <20110620164504.GC4749@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1690 Lines: 46 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/