Re: [patch 05/11] syslets: core code

From: bert hubert
Date: Thu Feb 15 2007 - 13:47:20 EST


On Thu, Feb 15, 2007 at 09:42:32AM -0800, Linus Torvalds wrote:

> We know one interface: the current aio_read() one. Nobody really _likes_
[...]

> Others? We don't know yet. And exposing complex interfaces that may not be
> the right ones is much *worse* than exposing simple interfaces (that
> _also_ may not be the right ones, of course - but simple and

>From humble userland, here's two things I'd hope to be able to do, although
I admit my needs are rather specialist.

1) batch, and wait for, with proper error reporting:
socket();
[ setsockopt(); ]
bind();
connect();
gettimeofday(); // doesn't *always* happen
send();
recv();
gettimeofday(); // doesn't *always* happen

I go through this sequence for each outgoing powerdns UDP query
because I need a new random source port for each query, and I
connect because I care about errrors. Linux does not give me random
source ports for UDP sockets.

When async, I can probably just drop the setsockopt (for
nonblocking). I already batch the gettimeofday to 'once per epoll
return', but quite often this is once per packet.

2) On the client facing side (port 53), I'd very much hope for a way to
do 'recvv' on datagram sockets, so I can retrieve a whole bunch of
UDP datagrams with only one kernel transition.

This would mean that I batch up either 10 calls to recv(), or one
'atom' of 10 recv's.

Both 1 and 2 are currently limiting factors when I enter the 100kqps domain
of name serving. This doesn't mean the rest of my code is as tight as it
could be, but I spend a significant portion of time in the kernel even at
moderate (10kqps effective) loads, even though I already use epoll. A busy
PowerDNS recursor typically spends 25% to 50% of its time on 'sy' load.

This might be due to my use of get/set/swap/makecontext though.

Bert

--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/