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 48FBDC47071 for ; Fri, 17 Nov 2023 12:10:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345894AbjKQMKO (ORCPT ); Fri, 17 Nov 2023 07:10:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345821AbjKQMKN (ORCPT ); Fri, 17 Nov 2023 07:10:13 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37648D49 for ; Fri, 17 Nov 2023 04:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700223009; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=FxZeqSyzArBoXMRwOJE+Ura8EkE7wjC2PJj+X2FJmxE=; b=QPEplUl26Jk97MncFe6OEbfinEk0liF5YPVs+a/pNjpujuk/gEdBeWVWsfSExwN02+13ZU QQR8lRsI2ecm3EAIGl8Nw0sw/xSALeUingRP38F3t8K6eTb5Nw0z+uf+HGTUyhNTWqPPHr b6menEzASUKlsTVnhx/xpIsqRqbTpTA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-146-_-crp8HjN-a76gkW3SOucA-1; Fri, 17 Nov 2023 07:10:06 -0500 X-MC-Unique: _-crp8HjN-a76gkW3SOucA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 88896101A53B; Fri, 17 Nov 2023 12:10:05 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.194.53]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 031D1C1290F; Fri, 17 Nov 2023 12:10:04 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 3AHCA0F12487662 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 17 Nov 2023 13:10:00 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 3AHC9uis2485185; Fri, 17 Nov 2023 13:09:56 +0100 Date: Fri, 17 Nov 2023 13:09:55 +0100 From: Jakub Jelinek To: Borislav Petkov Cc: Linus Torvalds , David Howells , kernel test robot , oe-lkp@lists.linux.dev, lkp@intel.com, linux-kernel@vger.kernel.org, Christian Brauner , Alexander Viro , Jens Axboe , Christoph Hellwig , Christian Brauner , Matthew Wilcox , David Laight , ying.huang@intel.com, feng.tang@intel.com, fengwei.yin@intel.com, linux-toolchains ML Subject: Re: [linus:master] [iov_iter] c9eec08bac: vm-scalability.throughput -16.9% regression Message-ID: Reply-To: Jakub Jelinek References: <202311061616.cd495695-oliver.sang@intel.com> <3865842.1700061614@warthog.procyon.org.uk> <20231115190938.GGZVUXcuUjI3i1JRAB@fat_crate.local> <20231116154406.GDZVY4xmFvRQt0wGGE@fat_crate.local> <20231117114421.GCZVdSFZ7DKtBol821@fat_crate.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231117114421.GCZVdSFZ7DKtBol821@fat_crate.local> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Fri, Nov 17, 2023 at 12:44:21PM +0100, Borislav Petkov wrote: > Might as well Cc toolchains... > > On Thu, Nov 16, 2023 at 11:48:18AM -0500, Linus Torvalds wrote: > > Hmm. I know about the '-mstringop-strategy' flag because of the fairly > > recently discussed bug where gcc would create a byte-by-byte copy in > > some crazy circumstances with the address space attributes: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657 > > I hear those stringop strategy heuristics are interesting. :) > > > But I incorrectly thought that "-mstringop-strategy=libcall" would > > then *always* do library calls. > > That's how I understood it too. BUT, reportedly, small and known sizes > are still optimized, which is exactly what we want. Sure. -mstringop-strategy affects only x86 expansion of the stringops from GIMPLE to RTL, while for small constant sizes some folding can happen far earlier in generic code. Similarly, the copy/store by pieces generic handling (straight-line code expansion of the builtins) is done in some cases without invoking the backend optabs which is the only expansion affected by the strategy. Note, the default strategy depends on the sizes, -mtune= in effect, whether it is -Os or -O2 etc. And the argument for -mmemcpy-strategy= or -mmemset-strategy= can include details on what sizes should be handled by which algorithm, not everything needs to be done the same. > > IOW, my assumption was just broken, and using > > "-mstringop-strategy=libcall" may well be the right thing to do. > > And here's where I'm wondering whether we should enable it for x86 only > or globally. I think globally because those stringop heuristics happen, > AFAIU, in the general optimization stage and thus target agnostic. -mstringop-strategy= option is x86 specific, so I don't see how you could enable it on other architectures. Anyway, if you are just trying to work-around bugs in specific compilers, please limit it to the affected compilers, overriding kernel makefiles forever with the workaround would mean you force perhaps suboptimal expansion in various cases. Jakub