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/gs

2010-04-24 Thread Alexander Best
tiny patch to fix a typo in the gsched(8) manual. ;)

-- 
Alexander Best
Index: sbin/geom/class/sched/gsched.8
===
--- sbin/geom/class/sched/gsched.8  (revision 207154)
+++ sbin/geom/class/sched/gsched.8  (working copy)
@@ -93,8 +93,8 @@
 on an already existing provider.
 .Pp
 A subsequent 'destroy' will remove the newly created geom and
-hook the provider back to the original geom.
-.Ar algorithm
+hook the provider back to the original geom
+.Ar algorithm .
 .It Cm configure
 Configure existing scheduling provider.  It supports the same options
 as the 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

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/gs

2010-04-24 Thread Bruce Cran
On Monday 12 April 2010 17:37:45 Luigi Rizzo wrote:
 Author: luigi
 Date: Mon Apr 12 16:37:45 2010
 New Revision: 206497
 URL: http://svn.freebsd.org/changeset/base/206497
 
 Log:
   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.

The example in gsched(8) says to use -s rr, but it looks like it should be 
-a rr?

-- 
Bruce Cran
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


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/gs

2010-04-15 Thread Attila Nagy

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)?

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


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/gs

2010-04-15 Thread Luigi Rizzo
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
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


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/gs

2010-04-15 Thread Ulrich Spörlein
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
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


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/gs

2010-04-14 Thread Pawel Jakub Dawidek
On Mon, Apr 12, 2010 at 11:05:12PM +0200, Luigi Rizzo wrote:
 On Mon, Apr 12, 2010 at 10:49:26PM +0200, Pawel Jakub Dawidek wrote:
 ...
   @@ -0,0 +1,19 @@
   +# GEOM_LIBRARY_PATH
   +# $FreeBSD$
   +
   +.PATH: /usr/src/sbin/geom/misc
   +
   +CFLAGS += -I/usr/src/sbin/geom
  
  This doesn't look right.
 
 probably a leftover from older versions of this code for 6.x .
 I will do more tests tomorrow (for 7.x at this point, there is
 no point in trying to support 6.x I believe) and try to remove
 it if not necessary.

As Rui said you should use ${.CURDIR} instead of hardcoding /usr/src/.

BTW. So you decided to implement insert/remove functionality after all.
I have some questions:

- It is implemented as internal gsched hack, which is a pity, because
  this might be very useful functionality for other classes in the future.
  Is there a plan to make it more general and move it to the GEOM itself?

- Why g_sched_flush_pending() operates on global structure? I think it
  will break if you try to insert and remove at the same time.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
p...@freebsd.org   http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!


pgpAKv7NSWhnx.pgp
Description: PGP signature


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/gs

2010-04-14 Thread Pawel Jakub Dawidek
On Wed, Apr 14, 2010 at 09:46:17AM +0200, Pawel Jakub Dawidek wrote:
 BTW. So you decided to implement insert/remove functionality after all.
 I have some questions:
 
 - It is implemented as internal gsched hack, which is a pity, because
   this might be very useful functionality for other classes in the future.
   Is there a plan to make it more general and move it to the GEOM itself?
 
 - Why g_sched_flush_pending() operates on global structure? I think it
   will break if you try to insert and remove at the same time.

One more thing:)

If I read code correctly, new provider has different name than the
original one. If my userland tool send command to my class and my class
tries to find provider by name by scaning existing geoms, it won't find
it, because provider's name is different.

Wouldn't it better to change old provider's name and use the name old
provider had for new provider? Sounds hackish...

Another thing that comes to my mind is possibility to create providers
that are not represented in /dev/. Name collision wouldn't be a problem
then. Also, it seems nicer to not polute /dev/ with such
proxy-providers.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
p...@freebsd.org   http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!


pgpUnuaFoXHiD.pgp
Description: PGP signature


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/gs

2010-04-14 Thread Luigi Rizzo
[Cc-ing Fabio as he may have more details]

On Wed, Apr 14, 2010 at 09:46:17AM +0200, Pawel Jakub Dawidek wrote:
 On Mon, Apr 12, 2010 at 11:05:12PM +0200, Luigi Rizzo wrote:
  On Mon, Apr 12, 2010 at 10:49:26PM +0200, Pawel Jakub Dawidek wrote:
  ...
@@ -0,0 +1,19 @@
+# GEOM_LIBRARY_PATH
+# $FreeBSD$
+
+.PATH: /usr/src/sbin/geom/misc
+
+CFLAGS += -I/usr/src/sbin/geom
   
   This doesn't look right.
  
  probably a leftover from older versions of this code for 6.x .
  I will do more tests tomorrow (for 7.x at this point, there is
  no point in trying to support 6.x I believe) and try to remove
  it if not necessary.
 
 As Rui said you should use ${.CURDIR} instead of hardcoding /usr/src/.

I thought i already fixed this yesterday.

 BTW. So you decided to implement insert/remove functionality after all.
 I have some questions:
 
 - It is implemented as internal gsched hack, which is a pity, because
   this might be very useful functionality for other classes in the future.
   Is there a plan to make it more general and move it to the GEOM itself?

yes there is such a plan -- of course if nobody has objections.
In principle it is only a library extensions with no modifications
to geom internals.

However, when we developed that last year, we hit some corner case
where removal of an active node causes either a race or (if you try
to protect from the race) a livelock. Fixing this may require some
small cleanup to geom internals (we discusses the issue with phk
at last EuroBSDCon. Fabio may give you more details, as far as i
remember the problem was that some geom code takes shortcuts instead
of following a chain of pointers, and this can end up in the wrong
place in case of a removal.)

For this reason, at this time i am not recommending to remove a
node from a chain with outstanding transactions until the issue is solved.

 - Why g_sched_flush_pending() operates on global structure? I think it
   will break if you try to insert and remove at the same time.

i need to check this.

cheers
luigi
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


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/gs

2010-04-14 Thread Fabio Checconi
 From: Luigi Rizzo ri...@iet.unipi.it
 Date: Wed, Apr 14, 2010 10:16:30AM +0200

 [Cc-ing Fabio as he may have more details]
 
...
  BTW. So you decided to implement insert/remove functionality after all.
  I have some questions:
  
  - It is implemented as internal gsched hack, which is a pity, because
this might be very useful functionality for other classes in the future.
Is there a plan to make it more general and move it to the GEOM itself?
 
 yes there is such a plan -- of course if nobody has objections.
 In principle it is only a library extensions with no modifications
 to geom internals.
 
 However, when we developed that last year, we hit some corner case
 where removal of an active node causes either a race or (if you try
 to protect from the race) a livelock. Fixing this may require some
 small cleanup to geom internals (we discusses the issue with phk
 at last EuroBSDCon. Fabio may give you more details, as far as i
 remember the problem was that some geom code takes shortcuts instead
 of following a chain of pointers, and this can end up in the wrong
 place in case of a removal.)
 
 For this reason, at this time i am not recommending to remove a
 node from a chain with outstanding transactions until the issue is solved.
 

I'm not sure I remember all the details, the major issues were:

  - g_disk_done() dereferences bio-parent-bio_to-geom-softc, thus
changing bio_to-geom on the fly was not possible with pending
request (they would find a wrong softc when bubbling up).  For
this reason we added a loop in g_insert_proxy() to wait for all
the pending requests to be completed prior to inserting the proxy;
but:

  - g_slice_finish_hot() completes requests in the event handling path,
thus said loop (executed from an event handler) could result in a
deadlock.  To avoid this (it should be far from being frequent,
considering the usages of hotspots in the slice code) g_insert_proxy()
fails if it takes too long to complete the old requests.

  - Some classes (from a quick look I've seen only g_mirror, but I'm
pretty sure there were some other ones) cache pointers to their
providers.  With these classes this implementation does not work.

For the scheduler this is not a big issue, because its natural
position is as close as possible to the disk device, but makes
the mechanism quite hard to use in a more generic context.


  - Why g_sched_flush_pending() operates on global structure? I think it
will break if you try to insert and remove at the same time.
 

If I'm not wrong, this should be safe because the global list is used only
under critical sections protected by the topology lock.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


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/gs

2010-04-14 Thread Pawel Jakub Dawidek
On Wed, Apr 14, 2010 at 06:05:54PM +0200, Fabio Checconi wrote:
   - Some classes (from a quick look I've seen only g_mirror, but I'm
 pretty sure there were some other ones) cache pointers to their
 providers.  With these classes this implementation does not work.

This can be easly changed to go though geom to provider. Many of my
classes do that.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
p...@freebsd.org   http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!


pgp3alHfLY40r.pgp
Description: PGP signature


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/gs

2010-04-12 Thread Pawel Jakub Dawidek
On Mon, Apr 12, 2010 at 04:37:45PM +, Luigi Rizzo wrote:
 Author: luigi
 Date: Mon Apr 12 16:37:45 2010
 New Revision: 206497
 URL: http://svn.freebsd.org/changeset/base/206497
 
 Log:
   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.

Nice work:)

 Added: head/sbin/geom/class/sched/Makefile
 ==
 --- /dev/null 00:00:00 1970   (empty, because file is newly added)
 +++ head/sbin/geom/class/sched/Makefile   Mon Apr 12 16:37:45 2010
 (r206497)
 @@ -0,0 +1,19 @@
 +# GEOM_LIBRARY_PATH
 +# $FreeBSD$
 +
 +.PATH: /usr/src/sbin/geom/misc
 +
 +CFLAGS += -I/usr/src/sbin/geom

This doesn't look right.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
p...@freebsd.org   http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!


pgpGCuW9vn2LH.pgp
Description: PGP signature