From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 692CFEB64D9 for ; Tue, 27 Jun 2023 21:44:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230249AbjF0Voc (ORCPT ); Tue, 27 Jun 2023 17:44:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43204 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230271AbjF0Voa (ORCPT ); Tue, 27 Jun 2023 17:44:30 -0400 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA59B2706 for ; Tue, 27 Jun 2023 14:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1687902269; x=1719438269; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Svsx6iLkTeK0LMangiMD1jOJsXTrHAZiBNrsTtgiQuY=; b=XVwPowF4ZQ2GhBFqsPaHBhHR0BWwMVf6EpQKuDId+E0BsC/gRcg4aZuI SiJQlBsJl9JTr82oeVWxhVkxbTNFty0FtjDm2Ob0Wr3d+QAPe3AmMq5WB YX3G2KBrvpfO/d+YKTsbqEl5UjJh8k9NSfQpUwlpWV4+4K+mKckJCYwsg 2Bfz3xlc6+pTadaHiM6cOgPom/TgUC+38LkFnUW3+KofKNXtaZsCqv15s MOgeYopfgpe4uBrX4Nsj5ovxWEOMBJr37Hb+9YtKHpkKEcbA9rtbmefBk yIwZqgfmMq/CslKdMP3Uvit2unN7rXlYy4WnL6URu7FnPeYNZu/xi4IGP A==; X-IronPort-AV: E=McAfee;i="6600,9927,10754"; a="361730451" X-IronPort-AV: E=Sophos;i="6.01,163,1684825200"; d="scan'208";a="361730451" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2023 14:44:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10754"; a="861255577" X-IronPort-AV: E=Sophos;i="6.01,163,1684825200"; d="scan'208";a="861255577" Received: from avandeve-mobl1.amr.corp.intel.com (HELO [10.209.78.231]) ([10.209.78.231]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2023 14:44:14 -0700 Message-ID: <1982e4b4-3858-d456-6c90-92782b95726a@linux.intel.com> Date: Tue, 27 Jun 2023 14:44:14 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [GIT PULL] x86/misc for 6.5 Content-Language: en-US To: Linus Torvalds , Borislav Petkov , Noah Goldstein , Dave Hansen Cc: x86-ml , lkml References: <20230627110038.GCZJrBVqu/4BfdyBeN@fat_crate.local> From: Arjan van de Ven In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/27/2023 1:11 PM, Linus Torvalds wrote: > On Tue, 27 Jun 2023 at 04:00, Borislav Petkov wrote: >> >> - Improve csum_partial()'s performance > > Honestly, looking at that patch, my reaction is "why did it get > unrolled in 64-byte chunks, if 40 bytes is the magic value"? > > Particularly when there is then that "do a carry op each 32 bytes to > make 32-byte chunks independent and increase ILP". So even the 64-byte > case isn't *actuall* doing a 64-byte unrolling, it's really doing two > 32-byte unrollings in parallel. > > So you have three "magic" values, and the only one that really matters > is likely the 40-byte one. > > Yes, yes, 64 bytes is the usual cacheline size, and is "traditional" > for unrolling. But there's nothing really magical about it here. > > End result: wouldn't it have been nice to just do 40-byte chunks, and > make the 64-byte "two overlapping 32-byte chunks" be two of the > 40-byte chunks. > > Something like the (ENTIRELY UNTESTED!) attached patch? > > Again: this is *not* tested. I took a quick look at the generated > assembly, and it looked roughly like what I expected it to look like, > but it may be complete garbage. > > I added a couple of "likely()" things just because it made the > generated asm look more natural (ie it followed the order of the > source code there), they are otherwise questionable annotations. > > Finally: did I already mention that this is completely untested? fwiw long flights and pools have a relation; I made a userspace testbench for this some time ago: https://github.com/fenrus75/csum_partial in case one would actually WANT to test ;)