Skip site navigation (1)Skip section navigation (2)
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>