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 6A415C197A0 for ; Thu, 16 Nov 2023 11:38:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345117AbjKPLiM convert rfc822-to-8bit (ORCPT ); Thu, 16 Nov 2023 06:38:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230401AbjKPLiK (ORCPT ); Thu, 16 Nov 2023 06:38:10 -0500 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ECC2B85 for ; Thu, 16 Nov 2023 03:38:06 -0800 (PST) Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with both STARTTLS and AUTH (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-56-nB6YrNm6ObaH_dAU9qjzxw-1; Thu, 16 Nov 2023 11:38:04 +0000 X-MC-Unique: nB6YrNm6ObaH_dAU9qjzxw-1 Received: from AcuMS.Aculab.com (10.202.163.6) by AcuMS.aculab.com (10.202.163.6) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Thu, 16 Nov 2023 11:38:08 +0000 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.048; Thu, 16 Nov 2023 11:38:08 +0000 From: David Laight To: 'David Howells' CC: 'Linus Torvalds' , Borislav Petkov , 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 , "ying.huang@intel.com" , "feng.tang@intel.com" , "fengwei.yin@intel.com" Subject: RE: [linus:master] [iov_iter] c9eec08bac: vm-scalability.throughput -16.9% regression Thread-Topic: [linus:master] [iov_iter] c9eec08bac: vm-scalability.throughput -16.9% regression Thread-Index: AQHaF/9mUr/d/cPMC0WC86r1pNT+UrB8tOywgAAGVICAAAkJMA== Date: Thu, 16 Nov 2023 11:38:08 +0000 Message-ID: References: <4c0c3ee6cfa84d21a807055bc1aa27b8@AcuMS.aculab.com> <202311061616.cd495695-oliver.sang@intel.com> <3865842.1700061614@warthog.procyon.org.uk> <20231115190938.GGZVUXcuUjI3i1JRAB@fat_crate.local> <97468.1700129643@warthog.procyon.org.uk> In-Reply-To: <97468.1700129643@warthog.procyon.org.uk> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: David Howells > Sent: 16 November 2023 10:14 > > David Laight wrote: > > > On haswell (which is now quite old) both 'rep movsb' and > > 'rep movsq' copy 16 bytes/clock unless the destination > > is 32 byte aligned when they copy 32 bytes/clock. > > Source alignment make no different, neither does byte > > alignment. > > I think the i3-4170 cpu I'm using is Haswell. Does that mean for my > particular cpu, just using inline "rep movsb" is the best choice? I've just looked at a slight old copy of the instruction timing doc from https://www.agner.org/optimize Apart from P4 (130 clock setup!) the setup cost for 'rep movs' is relatively small. I think everything since sandy bridge and bulldozer (except atoms, but including silvermont) do fast copies for 'rep movsb'. (But the C2758 atom we use claims erms.) I'd bet that the overhead for using 'rep movsb' for a short copy is less than that of the mispredicted branch (or two) to select the required code. That rather implies always using 'rep movsb' is best unless someone is compiling explicitly for an old cpu. And apart from P4 an explicit 'rep movsl' will be fastest then because the setup cost is minimal/zero. The cutoff for using 'rep movsb' for constant sized copies is probably also a lot less than you might expect. Especially assuming cold cache. This all makes that POS that gcc is inlining even more stupid. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)