From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752377AbbJWHOu (ORCPT ); Fri, 23 Oct 2015 03:14:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50256 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751092AbbJWHOs (ORCPT ); Fri, 23 Oct 2015 03:14:48 -0400 Subject: Re: [PATCH net-next RFC 2/2] vhost_net: basic polling support To: "Michael S. Tsirkin" , Rick Jones References: <1445491649-62614-1-git-send-email-jasowang@redhat.com> <1445491649-62614-2-git-send-email-jasowang@redhat.com> <20151022113824-mutt-send-email-mst@redhat.com> <562904D9.9080109@hpe.com> <20151022191456-mutt-send-email-mst@redhat.com> Cc: kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org From: Jason Wang Message-ID: <5629DE6A.9090205@redhat.com> Date: Fri, 23 Oct 2015 15:14:50 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151022191456-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/23/2015 12:16 AM, Michael S. Tsirkin wrote: > On Thu, Oct 22, 2015 at 08:46:33AM -0700, Rick Jones wrote: >> On 10/22/2015 02:33 AM, Michael S. Tsirkin wrote: >>> On Thu, Oct 22, 2015 at 01:27:29AM -0400, Jason Wang wrote: >>>> This patch tries to poll for new added tx buffer for a while at the >>>> end of tx processing. The maximum time spent on polling were limited >>>> through a module parameter. To avoid block rx, the loop will end it >>>> there's new other works queued on vhost so in fact socket receive >>>> queue is also be polled. >>>> >>>> busyloop_timeout = 50 gives us following improvement on TCP_RR test: >>>> >>>> size/session/+thu%/+normalize% >>>> 1/ 1/ +5%/ -20% >>>> 1/ 50/ +17%/ +3% >>> Is there a measureable increase in cpu utilization >>> with busyloop_timeout = 0? >> And since a netperf TCP_RR test is involved, be careful about what netperf >> reports for CPU util if that increase isn't in the context of the guest OS. Right, the cpu utilization is measured on host. >> >> For completeness, looking at the effect on TCP_STREAM and TCP_MAERTS, >> aggregate _RR and even aggregate _RR/packets per second for many VMs on the >> same system would be in order. >> >> happy benchmarking, >> >> rick jones > Absolutely, merging a new kernel API just for a specific > benchmark doesn't make sense. > I'm guessing this is just an early RFC, a fuller submission > will probably include more numbers. > Yes, will run more complete tests. Thanks