Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932861AbdC2Uas (ORCPT ); Wed, 29 Mar 2017 16:30:48 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:48090 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932865AbdC2UaJ (ORCPT ); Wed, 29 Mar 2017 16:30:09 -0400 Date: Wed, 29 Mar 2017 21:29:39 +0100 From: Al Viro To: Vineet Gupta Cc: "linux-arch@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Linus Torvalds , Richard Henderson , Russell King , Will Deacon , Haavard Skinnemoen , Steven Miao , Jesper Nilsson , Mark Salter , Yoshinori Sato , Richard Kuo , Tony Luck , Geert Uytterhoeven , James Hogan , Michal Simek , David Howells , Ley Foon Tan , Jonas Bonn , Helge Deller , Martin Schwidefsky , Ralf Baechle , Benjamin Herrenschmidt , Chen Liqin , "David S. Miller" , Chris Metcalf , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Chris Zankel Subject: Re: [RFC][CFT][PATCHSET v1] uaccess unification Message-ID: <20170329202939.GI29622@ZenIV.linux.org.uk> References: <20170329055706.GH29622@ZenIV.linux.org.uk> <3399faa9-795e-39db-42f5-7d1e10bbff9c@synopsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3399faa9-795e-39db-42f5-7d1e10bbff9c@synopsys.com> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 779 Lines: 15 On Wed, Mar 29, 2017 at 01:08:12PM -0700, Vineet Gupta wrote: > Hi Al, > > Thx for taking this up. It seems ARC was missing INLINE_COPY* switch likely due to > existing 2 variants (inline/out-of-line) we already have. > I've added a patch for that (attached too) - boot tested the series on ARC. BTW, I wonder if inlining all of the copy_{to,from}_user() is actually a win. It's probably arch-dependent and it would be nice if somebody compared performance with and without inlining those... ARC, in particular, has __arc_copy_{to,from}_user() inlining a whole lot, even in case of non-constant size and your patch, AFAICS, will inline all of it in *all* cases. It might end up being a win, but that's not apriori obvious... Do you have any profiling results in that area?