From patchwork Thu Apr 16 21:31:22 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Michael S. Tsirkin" X-Patchwork-Id: 26096 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@bilbo.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id 34B61B6F44 for ; Fri, 17 Apr 2009 07:32:37 +1000 (EST) Received: by ozlabs.org (Postfix) id 2624BDE20E; Fri, 17 Apr 2009 07:32:37 +1000 (EST) Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id BB0DFDE20D for ; Fri, 17 Apr 2009 07:32:36 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752238AbZDPVcb (ORCPT ); Thu, 16 Apr 2009 17:32:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751751AbZDPVca (ORCPT ); Thu, 16 Apr 2009 17:32:30 -0400 Received: from mail-fx0-f158.google.com ([209.85.220.158]:42700 "EHLO mail-fx0-f158.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750916AbZDPVca (ORCPT ); Thu, 16 Apr 2009 17:32:30 -0400 Received: by fxm2 with SMTP id 2so635524fxm.37 for ; Thu, 16 Apr 2009 14:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:subject :message-id:reply-to:mime-version:content-type:content-disposition :user-agent; bh=ovETfmI+3NEXpWSFMP9+YARUHH65ANYB0jw9NAR17sg=; b=NYJ0ARxJc9Jdic+07jf+fj2d2nY56nLsBvFQ4/Whyb/wDwTjv5FW38gM5oCFt2cSyW 6sxtiBWAced5ra1o9heVTAJmq3UyQcy1+bLH2PNpCCKcXZCNiHhJz6nDJYaZF1aVDg0H fCjkWlg0phoPFfXOtJkCU8JNs900+d+eEvRAY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:reply-to:mime-version :content-type:content-disposition:user-agent; b=t//n4eRzOh8O/P3AbO+/PO/WUqkjDySr8P9DamxVBEjRR5yXOlQlTt19rYJPoHy2nn PPoxIgyE6N7VFgE+QUdgZKwauRfJ4vI/WdNhKQT0Twksc/bBIR7XxuEudZb7QNJG9AGx rXX80RXzYVNYidaXgarRqYlxIAIsX+rcCxhDU= Received: by 10.86.94.11 with SMTP id r11mr1475140fgb.53.1239917547242; Thu, 16 Apr 2009 14:32:27 -0700 (PDT) Received: from dhcp-1-124.tlv.redhat.com (bzq-79-177-56-16.red.bezeqint.net [79.177.56.16]) by mx.google.com with ESMTPS id l12sm2211356fgb.16.2009.04.16.14.32.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Apr 2009 14:32:26 -0700 (PDT) Date: Fri, 17 Apr 2009 00:31:22 +0300 From: "Michael S. Tsirkin" To: Herbert Xu , "David S. Miller" , netdev@vger.kernel.org, Rusty Russell , Max Krasnyansky , "Rafael J. Wysocki" Subject: tun: performance regression in 2.6.30-rc1 Message-ID: <20090416213122.GB5894@dhcp-1-124.tlv.redhat.com> Reply-To: "Michael S. Tsirkin" MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi, I have a simple test that sends 10K packets out of a tap device. Average time needed to send a packet has gone up from 2.6.29 to 2.6.30-rc1. 2.6.30-rc1: #sh runsend time per packet: 7570 ns 2.6.29: #git checkout v2.6.29 -- drivers/net/tun.c #make modules modules_install #rmmod tun #sh runsend time per packet: 6337 ns I note that before 2.6.29, all tun skbs would typically be linear, while in 2.6.30-rc1, skbs for packet size > 1 page would be paged. And I found this comment by Rusty (it appears in the comment for commit f42157cb568c1eb02eca7df4da67553a9edae24a): My original version of this patch always allocate paged skbs for big packets. But that made performance drop from 8.4 seconds to 8.8 seconds on 1G lguest->Host TCP xmit. So now we only do that as a fallback. So just for fun, I did this: This makes all skbs linear in tun. And now: 2.6.30-rc1 made linear: #sh runsend time per packet: 6611 ns Two points of interest here: - It seems that linear skbs are generally faster. Would it make sense to make tun try to use linear skbs again, as it did before 2.6.29? - The new code seems to introduce some measurable overhead. My understanding is that it's main motivation is memory accounting - would it make sense to create a faster code path for the default case where accounting is disabled? Thanks, diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 37a5a04..1234d6b 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -520,7 +518,6 @@ static inline struct sk_buff *tun_alloc_skb(struct tun_struct *tun, int err; /* Under a page? Don't bother with paged skb. */ - if (prepad + len < PAGE_SIZE) linear = len; skb = sock_alloc_send_pskb(sk, prepad + linear, len - linear, noblock,