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
[EMAIL PROTECTED]
[EMAIL PROTECTED]
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
