Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp1375978rwb; Fri, 23 Sep 2022 11:44:13 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7kLlN5xE5qyVLEY18cXORI6hrJ6am4PoG0InG2FIQdvUAmOYe7TMldP29E3PJ867YYbCT2 X-Received: by 2002:a05:6a02:28b:b0:439:19d6:fad5 with SMTP id bk11-20020a056a02028b00b0043919d6fad5mr9065570pgb.591.1663958653360; Fri, 23 Sep 2022 11:44:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663958653; cv=none; d=google.com; s=arc-20160816; b=PqghTuZ6D9HvX9q6k6aoSqBIqXsszILeHlqpZd/JlqK96s4OY2uOD/vaQ/cKYu0QaW jKVFW/U9dx/xAWkPZgsUqHXHg3vkB2IFCBDI/8H0LNsKE++F9BB8WI/BlLDnnqoGz6Xd WQv1Vol2RolMraxfyF1y8gDkfgqjcYs2tA0zOQqR1cuji3Ho5q6QJ4+7SVbDfzExYE5T ZlwJzMq2JsUbfDEW5tkyK+1Mr7cfLValtM9VlCHNfkTaKz2+RynYCkOR1juZ/boJIiYh 0QvO3I/BCYLysYCychOJN4VaEr2bsAGufkjzRrl6TI9bwrr8R7LdN0qV4n/VRhRqJB5X 4Qdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=7MxhNKa1pvBKJp28Xv5e7IbSBJSuN9UMxkwoiOtIFKY=; b=tNl/TuW6WND3HaCW0natxUq9GJ7sqy7Y7VzmjLE5WoAjZu5RkZdzzUK8aaecsQE0X3 VlaUkNk3OFyJoQE3Ju6Xcoyx5NxNM0lLLKmnpZCL7T/OttcKx2Lt9SjmHv1vQlj52evV D2IokPFq8bdAm5ZUxJdE7WyJ+9y4U/5AKYr0BObVdyzS06hqZo6FBw+yxwMRbwTLjyiF W31EPYmyxNQ4vGERHgmDQELFxp43mN140SgPemxZq3iT/k0naY/pJL3YnLKaRtXFaGUc vzC9WkPqv61g8DumqwPyRwX7n4lIUP3vWHpQJcQcvt4o7PnqOjIjC54rM+fTcWdcaRvu WOfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=Uus7wQdU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d9-20020a655889000000b0043a6caebacesi9904639pgu.52.2022.09.23.11.44.01; Fri, 23 Sep 2022 11:44:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=Uus7wQdU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232225AbiIWSJk (ORCPT + 99 others); Fri, 23 Sep 2022 14:09:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232946AbiIWSIh (ORCPT ); Fri, 23 Sep 2022 14:08:37 -0400 Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A438413F29C for ; Fri, 23 Sep 2022 11:06:21 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id n124so767449oih.7 for ; Fri, 23 Sep 2022 11:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=7MxhNKa1pvBKJp28Xv5e7IbSBJSuN9UMxkwoiOtIFKY=; b=Uus7wQdUDWk44FDSQwJEpQB43nLtULU3gyubvF9ig6sLMhsYrBW/fT2eLkiDXP/j6F P8xdVmW3N/dGsk8WF9zq/xPDaInuSjL/UbWGHKH4lK2Gs07qj03YePC6fPmCyOZPJojh hz5XN5aYK3eXpYOOVGRIC5XgtO0t1EVMFkDuA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=7MxhNKa1pvBKJp28Xv5e7IbSBJSuN9UMxkwoiOtIFKY=; b=l+mmocHLizTAPPTpnytgxrkntZnd44q2Caeklv9kgPewEf8WnQ0DONJHuQWVI54UeV D0cryvyM+UHBgX/A6Y/ZKF/CvmMd+YsXQAq0oh8dhixQ8K/12rIIPzWUF1mEWRwdG5J+ PbpZEH/TjWK1BggHKLtoheOdmHOphdDsAWP8eMSflHTUDDb3bb7RUmo9Lbi1L0tvs4rV n0MF5h9CHMrl3lBhu3yuNC3bI7J35jhp0yauLM7qgJTD56JeG3axWRNBoqnx2QvIgifA 1TkieU9rO+9cPIMS+2IAO+HI6RCdFl2UsOx+j1P8IW+SapBYKYXUVa/7IxSPqeAEM/lb UbiQ== X-Gm-Message-State: ACrzQf2tnEUuO/vEienmzpa5IqWQGu+hhSMXV9BKzSc+nrumIYYBUBfY D5gN5lZZkxfY1rSDSl5ThmgRdMbbHSxpKA== X-Received: by 2002:a05:6808:1687:b0:347:cbd3:3dcf with SMTP id bb7-20020a056808168700b00347cbd33dcfmr4866546oib.53.1663956380417; Fri, 23 Sep 2022 11:06:20 -0700 (PDT) Received: from mail-oa1-f45.google.com (mail-oa1-f45.google.com. [209.85.160.45]) by smtp.gmail.com with ESMTPSA id x18-20020a056870b41200b0012d6f3d370bsm5144727oap.55.2022.09.23.11.06.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Sep 2022 11:06:18 -0700 (PDT) Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-11eab59db71so1295758fac.11 for ; Fri, 23 Sep 2022 11:06:16 -0700 (PDT) X-Received: by 2002:a05:6870:c0c9:b0:127:c4df:5b50 with SMTP id e9-20020a056870c0c900b00127c4df5b50mr5725740oad.126.1663956375518; Fri, 23 Sep 2022 11:06:15 -0700 (PDT) MIME-Version: 1.0 References: <20220923170218.1188423-1-ndesaulniers@google.com> In-Reply-To: From: Linus Torvalds Date: Fri, 23 Sep 2022 11:05:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] x86, mem: move memmove to out of line assembler To: Nick Desaulniers Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Kees Cook , linux-kernel@vger.kernel.org, llvm@lists.linux.dev, Andy Lutomirski Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 23, 2022 at 10:55 AM Nick Desaulniers wrote: > > We could remove __HAVE_ARCH_MEMMOVE from > arch/x86/include/asm/string_32.h for ARCH=i386 then rip this > arch-specific definition of memmove out. > > Might performance regressions be a concern with that approach? memmove() isn't particularly common, but it does happen for some paths that can be hot - the usual case of moving parts of an array around. I see filesystems and networking paths doing that. The generic memmove() is a horrendous byte-at-a-time thing and only good for bring-up of new architectures. That's not an option. But I'm looking at that x86-64 memcpy_orig, and I think it looks fairly good as a template for doing the same on x86-32. And we could get rid of the duplication on the x86-64 side. That said, your patch looks fine too, as a "minimal changes" thing. Linus