[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1288385116.2680.11.camel@edumazet-laptop>
Date: Fri, 29 Oct 2010 22:45:16 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: David Miller <davem@...emloft.net>
Cc: jj@...osbits.net, alban.crequy@...labora.co.uk,
shemminger@...tta.com, gorcunov@...nvz.org, adobriyan@...il.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
pauli.nieminen@...labora.co.uk, rweikusat@...gmbh.com
Subject: Re: [PATCH 0/1] RFC: poll/select performance on datagram sockets
Le vendredi 29 octobre 2010 à 13:40 -0700, David Miller a écrit :
> From: Jesper Juhl <jj@...osbits.net>
> Date: Fri, 29 Oct 2010 22:20:12 +0200 (CEST)
>
> > Sorry to intrude out of the blue without really understanding the kernel
> > side of most of the code in question, but if there's a performance
> > regression for applications using poll() shouldn't we address that so we
> > get back to the prior performance level rather than requireing all
> > userspace apps to switch to epoll() ??
>
> For such a pathological program like Alban's test case, I say
> absolutely not.
Yes, and with some perf tool help, we probably can find out how to
speedup the thing again, with no API change.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists