Re: hinting system for poll (was Re: /dev/poll vs. aio_)

[Niels Provos <pr...@citi.umich.edu>]

In message <19...@pizda.davem.net>, "David S. Miller" writes:
>   From: Niels Provos <pr...@citi.umich.edu>
>   Date: 	Mon, 17 May 1999 15:59:30 -0400
>
>   I am still working on this to make sure that it is bug free, but at
>   the moment I am fairly confident to make patches available within
>   about a week.
>
>Sounds quite interesting.
The hinting system is working correctly now.  The problem was that I
made a wrong assumption about lock_kernel().  I thought that it would
prevent the processing of network events, but it only seems to prevent
other syscalls from executing?

So I am using spin_lock_irqsave now to access shared data.  Shared
data being the hints that are accessed in do_select(), do_poll() and
the network stack.  The irqsave version of spin_lock is supposed to be
very slow but just using spin_lock leads to deadlocks.  Is there any
other way that this could be handled?

The test system I have been using for benchmarking is a 4-way Xeon
450Mhz.  When I run httpperf from another machine connected via 100
Mbit ethernet, the reply rate for requests never seems to exceed 1200
r/s.  I noticed that there are never more than 4000 sockets in the
system.  Is there a way to increase this number?  Also most of the
sockets are in TIME_WAIT and readprofile shows that a large amount of
the CPU time is spent in the tcp_timewait_* functions.

I have implemented the hinting system on top of 2.2.3-ac4.

Any ideas?

Greetings,
 Niels.