Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755687AbbGPSRc (ORCPT ); Thu, 16 Jul 2015 14:17:32 -0400 Received: from shards.monkeyblade.net ([149.20.54.216]:40158 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754864AbbGPSRb (ORCPT ); Thu, 16 Jul 2015 14:17:31 -0400 Date: Thu, 16 Jul 2015 11:17:29 -0700 (PDT) Message-Id: <20150716.111729.822179499552193763.davem@davemloft.net> To: tom@herbertland.com Cc: dvlasenk@redhat.com, tgraf@suug.ch, alexander.h.duyck@redhat.com, kadlec@blackhole.kfki.hu, herbert@gondor.apana.org.au, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] jhash: Deinline jhash, jhash2 and __jhash_nwords From: David Miller In-Reply-To: References: <1437050416-13295-1-git-send-email-dvlasenk@redhat.com> X-Mailer: Mew version 6.6 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Thu, 16 Jul 2015 11:17:30 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1408 Lines: 35 From: Tom Herbert Date: Thu, 16 Jul 2015 08:43:25 -0700 > On Thu, Jul 16, 2015 at 5:40 AM, Denys Vlasenko wrote: >> This patch deinlines jhash, jhash2 and __jhash_nwords. >> >> It also removes rhashtable_jhash2(key, length, seed) >> because it was merely calling jhash2(key, length, seed). >> >> With this .config: http://busybox.net/~vda/kernel_config, >> after deinlining these functions have sizes and callsite counts >> as follows: >> >> __jhash_nwords: 72 bytes, 75 calls >> jhash: 297 bytes, 111 calls >> jhash2: 205 bytes, 136 calls >> > jhash is used in several places in the critical data path. Does the > decrease in text size justify performance impact of not inlining it? Tom took the words right out of my mouth. Denys, you keep making deinlining changes like this all the time, like a robot. But I never see you make any effort to look into the performance nor code generation ramifications of your changes. And frankly that makes your patches quite tiring to deal with. Your changes potentially have large performance implications, yet you don't put any effort into considering that aspect at all. -- 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/