Date: Thu, 10 Sep 2009 09:25:03 -0400
From: Vivek Goyal <vgoyal@redhat.com>
To: Ryo Tsuruta <ryov@valinux.co.jp>
Cc: riel@redhat.com, linux-kernel@vger.kernel.org, dm-devel@redhat.com,
       jens.axboe@oracle.com, agk@redhat.com, akpm@linux-foundation.org,
       nauman@google.com, guijianfeng@cn.fujitsu.com, jmoyer@redhat.com,
       balbir@linux.vnet.ibm.com
Subject: Re: Regarding dm-ioband tests
Message-ID: <20090910132503.GA29559@redhat.com>
References: <20090908134244.GA15974@redhat.com> <20090909.190146.59669568.ryov@valinux.co.jp> <20090909143159.GC8256@redhat.com> <20090910.124547.71116284.ryov@valinux.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090910.124547.71116284.ryov@valinux.co.jp>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1812
Lines: 44

On Thu, Sep 10, 2009 at 12:45:47PM +0900, Ryo Tsuruta wrote:
> Hi Vivek,
> 
> Vivek Goyal <vgoyal@redhat.com> wrote:
> > > In addition,
> > > there are devices which doesn't use standard IO schedulers, and
> > > dm-ioband can work on even such devices.
> > 
> > This is a interesting use case. Few thoughts.
> > 
> > - Can't io scheduling mechanism of these devices make use of elevator and
> >   elevator fair queuing interfaces to take advantage of io controlling
> >   mechanism. It should not be too difficult. Look at noop. It has
> >   just 131 lines of code and it now supports hierarchical io scheduling.
> >  
> >   This will come with request queue and its merging and plug/unplug
> >   mechanism. Is that an issue?
> >
> > - If not, then yes, for these corner cases, io scheduler based controller
> >   does not work as it is.
> 
> I have a extreme fast SSD and its device driver provides its own
> make_request_fn(). So the device driver intercepts IO requests and the
> subsequent processes are done within it.

IMHO, in those cases these SSD driver needs to hook into block layer's request
queue mechanism if they need io controlling mechanism instead of we coming
up a device mapper module.

Think of it that if somebody needs CFQ like tasks classes and prio
suported on these devices, should we also come up with another device
mapper module "dm-cfq"?

Jens, I am wondering if similiar concerns have popped in the past also for
CFQ also? Somebody asking to support task prio and classes on devices which
don't use standard IO scheduler?

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/