From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755629AbaICHAd (ORCPT ); Wed, 3 Sep 2014 03:00:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11828 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753334AbaICHAc (ORCPT ); Wed, 3 Sep 2014 03:00:32 -0400 Message-ID: <5406BC69.2090508@redhat.com> Date: Wed, 03 Sep 2014 14:59:53 +0800 From: Jason Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Eliezer Tamir , Eric Dumazet CC: Ingo Molnar , Mike Galbraith , davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, mst@redhat.com, Peter Zijlstra , "Ingo Molnar jacob.e.keller@intel.com" Subject: Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable References: <1408608310-13579-1-git-send-email-jasowang@redhat.com> <1408608310-13579-2-git-send-email-jasowang@redhat.com> <1408683665.5648.69.camel@marge.simpson.net> <20140822073653.GA7372@gmail.com> <53F70887.8030602@redhat.com> <1408716976.5604.18.camel@edumazet-glaptop2.roam.corp.google.com> <53FB3715.7070009@linux.intel.com> <53FC3466.8000304@redhat.com> <5404186E.4090409@linux.intel.com> <54053AF8.6070907@redhat.com> <54055D9F.7000108@linux.intel.com> <54056459.4060100@redhat.com> <5406B365.5040604@linux.intel.com> In-Reply-To: <5406B365.5040604@linux.intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/03/2014 02:21 PM, Eliezer Tamir wrote: > On 02/09/2014 09:31, Jason Wang wrote: >> On 09/02/2014 02:03 PM, Eliezer Tamir wrote: >>> On 02/09/2014 06:35, Jason Wang wrote: >>>> Not sure whether this method will scale considering thousands of sockets >>>> and processes. >>> There may be millions of sockets, but in most cases only a handful of >>> device queues per CPU to busy poll on. I have tested the epoll rfc >>> code with hundreds of thousands of sockets and one or two device >>> queues and is scales pretty well. >>> >>> The part I don't like in that code is the cumbersome mechanism I used >>> to track the socket -> queue relationship. I think that if I had more >>> time to work on it, I would instead look into extending the epoll >>> interface so that libevent can tell the kernel what it wants, instead >>> of having the busypoll code try and learn it. >> I'd like to have a look at this rfc. Could you please give me a pointer? >> I've done a quick search on kernel mailing list but didn't find it. > https://lkml.org/lkml/2013/8/21/192 > > Cheers, > Eliezer > -- Thanks. I will have a look at this series.