Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753040AbbH1W3o (ORCPT ); Fri, 28 Aug 2015 18:29:44 -0400 Received: from mail-pa0-f43.google.com ([209.85.220.43]:34213 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752662AbbH1W3m (ORCPT ); Fri, 28 Aug 2015 18:29:42 -0400 Message-ID: <1440800980.8932.66.camel@edumazet-glaptop2.roam.corp.google.com> Subject: Re: [PATCH RFC V2 2/2] net: Optimize snmp stat aggregation by walking all the percpu data at once From: Eric Dumazet To: Joe Perches Cc: David Miller , raghavendra.kt@linux.vnet.ibm.com, edumazet@google.com, kuznet@ms2.inr.ac.ru, jmorris@namei.org, yoshfuji@linux-ipv6.org, kaber@trash.net, jiri@resnulli.us, hannes@stressinduktion.org, tom@herbertland.com, azhou@nicira.com, ebiederm@xmission.com, ipm@chirality.org.uk, nicolas.dichtel@6wind.com, serge.hallyn@canonical.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, anton@au1.ibm.com, nacc@linux.vnet.ibm.com, srikar@linux.vnet.ibm.com Date: Fri, 28 Aug 2015 15:29:40 -0700 In-Reply-To: <1440797172.11525.161.camel@perches.com> References: <1440610653-14210-3-git-send-email-raghavendra.kt@linux.vnet.ibm.com> <20150827.113823.214019265460582055.davem@davemloft.net> <55E00238.10909@linux.vnet.ibm.com> <20150828.112413.424099339331017970.davem@davemloft.net> <1440789654.11525.137.camel@perches.com> <1440794020.8932.45.camel@edumazet-glaptop2.roam.corp.google.com> <1440795211.11525.146.camel@perches.com> <1440795336.8932.46.camel@edumazet-glaptop2.roam.corp.google.com> <1440796183.11525.153.camel@perches.com> <1440796487.8932.48.camel@edumazet-glaptop2.roam.corp.google.com> <1440797172.11525.161.camel@perches.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1157 Lines: 29 On Fri, 2015-08-28 at 14:26 -0700, Joe Perches wrote: > Always a possibility, but I don't think so. > > > put_unaligned is happening on a space allocated from rtnetlink skb, not > > the temp space needed to perform the per cpu folding. > > That's why I suggested changing the snmp_fill_stats arguments. > > If the naturally aligned allocated u64 array is used and then > copied as a block to the rtnetlink skb, I believe there's no > alignment issue that would require put_unaligned. 1) u64 array[XX] on stack is naturally aligned, kzalloc() wont improve this at all. Not sure what you believe. 2) put_unaligned() is basically a normal memory write on x86. memcpy(dst,src,...) will have a problem anyway on arches that care, because src & dst wont have same alignment. 288 bytes on stack in a leaf function in this path is totally fine, it is not like we're calling ext4/xfs/nfs code after this point. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/