Date: Thu, 15 Apr 2010 18:49:23 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uqs@spoerlein.net> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: svn-src-head@FreeBSD.org, Attila Nagy <bra@fsn.hu>, Luigi Rizzo <luigi@FreeBSD.org>, src-committers@FreeBSD.org, fabio@gandalf.sssup.it Subject: Re: svn commit: r206497 - in head: sbin/geom/class sbin/geom/class/sched sys/geom/sched sys/modules/geom sys/modules/geom/geom_sched sys/modules/geom/geom_sched/gs_sched sys/modules/geom/geom_sched/gsc... Message-ID: <20100415164922.GD92627@acme.spoerlein.net> In-Reply-To: <20100415151557.GA98341@onelab2.iet.unipi.it> References: <201004121637.o3CGbjSK080066@svn.freebsd.org> <4BC724DF.7010907@fsn.hu> <20100415151557.GA98341@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 15.04.2010 at 17:15:57 +0200, Luigi Rizzo wrote: > On Thu, Apr 15, 2010 at 04:38:23PM +0200, Attila Nagy wrote: > > On 04/12/2010 06:37 PM, Luigi Rizzo wrote: > > > Bring in geom_sched, support for scheduling disk I/O requests > > > in a device independent manner. Also include an example anticipatory > > > scheduler, gsched_rr, which gives very nice performance improvements > > > in presence of competing random access patterns. > > > > > > This is joint work with Fabio Checconi, developed last year > > > and presented at BSDCan 2009. You can find details in the > > > README file or at > > > > > Are there any plans to bring in something like Linux's ionice (or even > > better solutions)? Is it possible to do it easily at all (the user and > > GEOM are seemingly very far from each other)? > > I can easily[*] modify the I/O priority/weight of process or threads, > but you have to keep in mind that once a request is intercepted by > the filesystem code (e.g. for delayed writes, or avoid duplication > of pending reads), by the time it hits the disk it is not trivial > to tell who should be charged for it. > > This is an area where we still need to experiment a bit > (especially to find on which process issues which request, > say for metadata, delayed writes, shared reads). > > [*] the 'easy' way is put the information in an external hash table > and look it up using as a search key either of uid, gid, <pid/struct > thread *>. I think we did something like this in the GSOC2005 > project on disk scheduling. A more intrusive way involves extending > the struct thread with an extra field to store the io priority. What would already be helpful, is an I/O time measurement of the overall system and have that displayed in, eg., vmstat like Linux and Solaris do. It gives a better measure of if a system is CPU bound or I/O bound or neither. Can the scheduler help here? Uli
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100415164922.GD92627>