From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: [PATCH RFC 3/3] virtio infrastructure: example block driver Date: Mon, 4 Jun 2007 15:54:33 +0200 Message-ID: <20070604135433.GG32105@kernel.dk> References: <1180613947.11133.58.camel@localhost.localdomain> <1180614044.11133.61.camel@localhost.localdomain> <1180614091.11133.63.camel@localhost.localdomain> <465EC637.7020504@de.ibm.com> <1180654765.10999.6.camel@localhost.localdomain> <465FC65C.6020905@de.ibm.com> <20070601131315.GW32105@kernel.dk> <4664164A.40604@de.ibm.com> <20070604134322.GC32105@kernel.dk> <1180965161.25878.47.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Jimi Xenidis , Stephen Rothwell , Xen Mailing List , "jmk-zzFmDc4TPjtKvsKVC3L/VUEOCMrvLtNR@public.gmane.org" , Herbert Xu , carsteno-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org, mschwid2-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org, virtualization , kvm-devel , Suzanne McIntosh , Christian Borntraeger To: Rusty Russell Return-path: Content-Disposition: inline In-Reply-To: <1180965161.25878.47.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org On Mon, Jun 04 2007, Rusty Russell wrote: > On Mon, 2007-06-04 at 15:43 +0200, Jens Axboe wrote: > > On Mon, Jun 04 2007, Carsten Otte wrote: > > > Jens Axboe wrote: > > > >On Fri, Jun 01 2007, Carsten Otte wrote: > > > >>With regard to compute power needed, almost none. The penalty is > > > >>latency, not overhead: A small request may sit on the request queue to > > > >>wait for other work to arrive until the queue gets unplugged. This > > > >>penality is compensated by the benefit of a good chance that more > > > >>requests will be merged during this time period. > > > >>If we have this method both in host and guest, we have twice the > > > >>penalty with no added benefit. > > > > > > > >I don't buy that argument. We can easily expose the unplug delay, so you > > > >can kill it at what ever level you want. Or you could just do it in the > > > >driver right now, but that is a bit hackish. > > > That would be preferable if the device driver can chose the unplug > > > delay, or even better it could be (guest)sysfs tuneable. > > > > Right. We probably should make it sysfs configurable in any case, right > > now it's a (somewhat) policy decision in the kernel with the delay and > > unplug depth. > > The danger is that it's just another knob noone knows how to use. > Perhaps simply setting it to 0 for the noop scheduler will cover all > known cases? Most people should not fiddle with it, the defaults are there for good reason. I can provide a blk_queue_unplug_thresholds(q, depth, delay) helper that you could use for the virtualized drivers, perhaps that would be better for that use? -- Jens Axboe ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/