Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753763AbdF2Vk4 (ORCPT ); Thu, 29 Jun 2017 17:40:56 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:35416 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753438AbdF2Vkz (ORCPT ); Thu, 29 Jun 2017 17:40:55 -0400 MIME-Version: 1.0 In-Reply-To: <4533a1d101fd460f80e21329a34928fad521c1d4.1498744345.git.pabeni@redhat.com> References: <4533a1d101fd460f80e21329a34928fad521c1d4.1498744345.git.pabeni@redhat.com> From: Linus Torvalds Date: Thu, 29 Jun 2017 14:40:53 -0700 X-Google-Sender-Auth: GDhAp6PZVKBvLuIbv-74rbZ_btg Message-ID: Subject: Re: [PATCH] x86/uaccess: optimize copy_user_enhanced_fast_string for short string To: Paolo Abeni Cc: "the arch/x86 maintainers" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Kees Cook , Hannes Frederic Sowa , Alan Cox , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 741 Lines: 17 Looks ok to me, so Ack, fwiw. I've have long hoped that Intel would actually fix their microcode overhead issue so that we could get rid of all this and just inline "rep movsb", but that hasn't been happening, so this patch looks fine. Side niote: I suspect the copy_user_generic_string() might as well use the same logic too, rather than having a different cut-off (8 bytes) to a worse implementation (rep movsb on architectures that don't mark themselves with the enhanced string). Linus On Thu, Jun 29, 2017 at 6:55 AM, Paolo Abeni wrote: > According to the Intel datasheet, the rep movsb instruction > exposes a relevant setup cost - 50 ticks - which affect > badly short string copy operation.