Date: Thu, 15 Apr 2010 17:15:57 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Attila Nagy <bra@fsn.hu>, fabio@gandalf.sssup.it Cc: svn-src-head@FreeBSD.org, Luigi Rizzo <luigi@FreeBSD.org>, src-committers@FreeBSD.org 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: <20100415151557.GA98341@onelab2.iet.unipi.it> In-Reply-To: <4BC724DF.7010907@fsn.hu> References: <201004121637.o3CGbjSK080066@svn.freebsd.org> <4BC724DF.7010907@fsn.hu>
next in thread | previous in thread | raw e-mail | index | archive | help
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. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100415151557.GA98341>