Giant-free polling [PATCH]

[Bosko Milekic]

On Fri, Mar 11, 2005 at 03:14:50PM +0100, Pawel Jakub Dawidek wrote:
> On Fri, Mar 11, 2005 at 04:55:25PM +0300, dima wrote:
> +> I thought about using list also, but considered it to bring
> +> too much overhead to the code. The original idea of handling arrays
> +> seems to be very elegant.
> 
> Overhead? Did you run any benchmarks to prove it?
> I find list-version much more elegant that using an array.

  You should however be aware that iterating over an array of references
  as opposed to a list in the polling path, if you only consider the
  cost of iteration itself, is faster on both SMP and UP.  With the list
  approach, you will have to bring in at least three items into cache,
  at each iteration:

  	(1) The list node;

	(2) The list node's member (the 'pr' reference data in your patch);

	(3) The device's mutex.

  With the array approach, you will remove (1).

  If the relative frequency of insertions and removals is low (which I
  think it is in the polling case), you ought to consider doing the
  array thing (considering the predictable scheduling nature of polling,
  you could use the cache advantages due to the use of the array).

  Also, you will still be able to implement dynamic removal/insertion
  from/to the polling array.  The fact that it is an array might just
  require re-allocation, not a big deal.

> I also don't like the idea of calling handler method with two locks
> held (one sx and one mutex)...

  Yeah, this should be re-worked.  However, the use of the sx lock is
  neat.  Unfortunately, our sx lock implementation always resorts to
  using a regular mutex lock, even when doing a shared lock (read only)
  acquisition.  Since the window of the underlying sx lock mutex is
  relatively short, in most cases the performance advantage of using the
  sx lock is noticable.  However, if the window of the original mutex is
  also short (compared to the sx lock window), then I wonder if it is
  worth it.  The sx lock is really only designed for optimizing
  long-reads, in our case.

Regards,
-- 
Bosko Milekic
bmilekic at technokratis.com
bmilekic at FreeBSD.org