tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: select/poll optimization



Hello,

Andrew Doran <ad%netbsd.org@localhost> wrote:
> Currently select() and poll() synchronize using a global mutex. The below
> diff changes them to use per-CPU state, and removes the locking in
> selrecord(). In the best case there is no lock contention internal to
> select() or poll() with the patch, and in the worse case, all state is
> hashed out by a factor of $ncpu so it should scale as CPUs are added.
> 
> In the few tests I have done there is either no lock contention or it's just
> background noise. rmind@ and I have been discussing an approach using a
> 'thread x descriptor' array to store state, and do fine grained locking
> based on that, but I think the per-CPU approach is better because a lot less
> synchronization is needed, and no changes are needed to drivers.
> 
>       http://www.netbsd.org/~ad/percpu-select.diff
> 
> Comments?

As discussed with Andrew, here is the per-thread approach with the array of
descriptors to store state:

http://www.netbsd.org/~rmind/perthread-select.diff

My arguments for this way:
- Locking is more fine-grained, and I think it would perform better in systems
  with >= 8 CPUs. That is a long-term solution.
- Only selector LWP is awoken, there are no case of collision like in current
  implementation, when all selecting LWPs are awoken to re-check the state.
- Our second goal is to avoid calling selscan/pollscan twice, for that we
  need per-thread storage anyway.

Also, hope I have done the changes for the drivers:
http://mail-index.netbsd.org/tech-kern/2008/02/24/msg000449.html
This patch depends on these changes.

Please comment :)

-- 
Best regards,
Mindaugas
www.NetBSD.org


Home | Main Index | Thread Index | Old Index