From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752351AbeCTJIK (ORCPT ); Tue, 20 Mar 2018 05:08:10 -0400 Received: from mail-wm0-f44.google.com ([74.125.82.44]:51757 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751790AbeCTJIG (ORCPT ); Tue, 20 Mar 2018 05:08:06 -0400 X-Google-Smtp-Source: AG47ELtNTDJEwFbhYYVgkAr9MgIbY7m4R4z2OYweWBIHMeVI1vrAbOBPVDFPT2x5el+nXuRtNw+WmA== Date: Tue, 20 Mar 2018 10:08:02 +0100 From: Ingo Molnar To: Thomas Gleixner Cc: David Laight , "'Rahul Lakkireddy'" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" , "mingo@redhat.com" , "hpa@zytor.com" , "davem@davemloft.net" , "akpm@linux-foundation.org" , "torvalds@linux-foundation.org" , "ganeshgr@chelsio.com" , "nirranjan@chelsio.com" , "indranil@chelsio.com" , Andy Lutomirski , Peter Zijlstra , Fenghua Yu , Eric Biggers Subject: Re: [RFC PATCH 0/3] kernel: add support for 256-bit IO access Message-ID: <20180320090802.qw4tqjmhy6yfd6sf@gmail.com> References: <7f0ddb3678814c7bab180714437795e0@AcuMS.aculab.com> <7f8d811e79284a78a763f4852984eb3f@AcuMS.aculab.com> <20180320082651.jmxvvii2xvmpyr2s@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Thomas Gleixner wrote: > > So I do think we could do more in this area to improve driver performance, if the > > code is correct and if there's actual benchmarks that are showing real benefits. > > If it's about hotpath performance I'm all for it, but the use case here is > a debug facility... > > And if we go down that road then we want a AVX based memcpy() > implementation which is runtime conditional on the feature bit(s) and > length dependent. Just slapping a readqq() at it and use it in a loop does > not make any sense. Yeah, so generic memcpy() replacement is only feasible I think if the most optimistic implementation is actually correct: - if no preempt disable()/enable() is required - if direct access to the AVX[2] registers does not disturb legacy FPU state in any fashion - if direct access to the AVX[2] registers cannot raise weird exceptions or have weird behavior if the FPU control word is modified to non-standard values by untrusted user-space If we have to touch the FPU tag or control words then it's probably only good for a specialized API. Thanks, Ingo