Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754130AbdCFRlL (ORCPT ); Mon, 6 Mar 2017 12:41:11 -0500 Received: from ale.deltatee.com ([207.54.116.67]:46883 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753027AbdCFRlD (ORCPT ); Mon, 6 Mar 2017 12:41:03 -0500 To: "H. Peter Anvin" , Borislav Petkov , Linus Torvalds References: <20170304224341.zfp4fl37ypt57amg@pd.tnic> <5CCEF10D-5647-4503-A398-0681DF2C8847@zytor.com> <20170305001447.kcxignj3nsq35vci@pd.tnic> <20170305003349.6kgq4ovj7ipezfxu@pd.tnic> <20170305095059.l4od2yjqm5yxx6ln@pd.tnic> <20170305195432.6occvwaujq3l4ejl@pd.tnic> <5be40886-b468-d828-f948-2ad99b95a230@deltatee.com> <471eb23d-40f2-0c66-c9db-c8b0b5204c07@zytor.com> Cc: Thomas Gleixner , Ingo Molnar , Tony Luck , Al Viro , the arch/x86 maintainers , Linux Kernel Mailing List From: Logan Gunthorpe Message-ID: <2ed5cdac-7eb1-5444-c030-94e5504f7235@deltatee.com> Date: Mon, 6 Mar 2017 10:12:41 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <471eb23d-40f2-0c66-c9db-c8b0b5204c07@zytor.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.111 X-SA-Exim-Rcpt-To: linux-kernel@vger.kernel.org, x86@kernel.org, viro@zeniv.linux.org.uk, tony.luck@intel.com, mingo@redhat.com, tglx@linutronix.de, torvalds@linux-foundation.org, bp@suse.de, hpa@zytor.com X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: Question Regarding ERMS memcpy X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 770 Lines: 21 On 06/03/17 12:28 AM, H. Peter Anvin wrote: > On 03/05/17 23:01, Logan Gunthorpe wrote: >> >> On 05/03/17 12:54 PM, Borislav Petkov wrote: >>> Logan, wanna give that a try, see if it takes care of your issue? >> >> Well honestly my issue was solved by fixing my kernel config. I have no >> idea why I had optimize for size in there in the first place. >> > > Yes, to gcc "optimize for size" means exactly that... intended for cases > where saving storage (e.g. ROM) or code download time is paramount. I agree and understand, however placing a poorly performing _inline_ memcpy instead of a single call instruction to a performant memcopy probably took more code space in the end. So like Linus, I just have to scratch my head at the -Os optimization option. Logan