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

Niels Provos (provos@citi.umich.edu)
Thu, 20 May 1999 00:18:57 -0400

In message <199905180242.TAA01699@pizda.davem.net>, "David S. Miller" writes:
> From: Niels Provos <provos@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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/