Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp4122530pxb; Mon, 4 Oct 2021 18:06:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyn9wMhQPBltcXFtFcvWJu/+Ar+uJ+yawf7Zhnf4gjOBXp00AzWNGr1Ss5/R1hOLcL3bm8I X-Received: by 2002:a17:906:c007:: with SMTP id e7mr15065751ejz.456.1633395963533; Mon, 04 Oct 2021 18:06:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633395963; cv=none; d=google.com; s=arc-20160816; b=nxSqi+eKaO54aK6q7nj0DvykiYnzvOErJioVMQgYMtv/3MT4CRWb7VBlb8w063M9wR NgayYeFf+HaDoWoga1SNjOkxKXDnAPU0d0C5RvpVQ4S/LzcVBCBSoHUKCMpVlCGdo81/ G7E38tZ0snuIrlxfe9dLHDi33gIT2BX6v2f42H6kgmUhmfsPvELsRSqYrTwD+drfNQkS twy0UYhzJqL34ef5L7RMjAyYFRnQAVhUfVnyA4/TtddbHI7r8PwIgcrDUXB2mNNm0+3C A2OHpNMVEHrsO9pTCJdSndFOoXcgf4ZbYKV0tdGAIQ3L2iID5iI1vBoHXpu0l9K+/4Ba Lnew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:to:from:cc:in-reply-to:subject:date:dkim-signature; bh=oebmTSxmq+zU8Utjs0yaAqanKgzPEsj+GJBxRd8logo=; b=HwAFcMDlCu4TpH3QD1DR+BSIfF2u/FFUgHEljNmZbECErvkol6UBsR9XcMuFUwLMKB 1rfCZbt/1orZKtUoX19LL3ENoM7/Pu+yYdOM47MRFBuiP+flRq+vqW8weLEt1HkVZisR kzF+Eay7SxTnJiQAy7gYZydtERVLWJCRai+/JMmxm+VWhMrOX+LybwlzvQCGI2zpJAGw gGCsXX0Kcod3gYuCUdE8liGmMeQY4Zp0uwMXy24RuftThRL58G8D6Z3efIZG8VWnoAiB jC5Bk9UWQHjgZeh4pCG7pqqdkoooOznTvBDF5bQxhSrO8Ba+553S1Akh7f5Dy+xGspxb aKsg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dabbelt-com.20210112.gappssmtp.com header.s=20210112 header.b=V2iUDB19; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s15si23736676edd.19.2021.10.04.18.05.39; Mon, 04 Oct 2021 18:06:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@dabbelt-com.20210112.gappssmtp.com header.s=20210112 header.b=V2iUDB19; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229659AbhJEBGN (ORCPT + 99 others); Mon, 4 Oct 2021 21:06:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229549AbhJEBGM (ORCPT ); Mon, 4 Oct 2021 21:06:12 -0400 Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EE9B2C061745 for ; Mon, 4 Oct 2021 18:04:22 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id b65so18320663qkc.13 for ; Mon, 04 Oct 2021 18:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=oebmTSxmq+zU8Utjs0yaAqanKgzPEsj+GJBxRd8logo=; b=V2iUDB19iERQnJXZioGUMJdM/uynjFuRplbo7a5cEjDjxHwD2V8DwueeGPziYpbB71 Bi9liJ6HB2HHZX6lxu+oHLksFzHeBVlU+X0Nd6OowCRe7v7npgTonODB4rqmB3qVEqw/ jPGpQidXVV8GXapY/RU2rL3Fyjj1axEjXQnoedoWQNonB6JXkWMVrpKM+o5p3m0Ycs2Q nkodGtZjkgnRUL5jEe95IomrgwwUY8EkQtpglV6mKWZOmXwzD/nwEuLhYOuXNG7rGVeN nYQTN8FwNRwge3tobOp0kDWk3Aj3ml6KVwepwzNcWTatc7yS9ioeSUidAKzg2Ffmq+zg vILw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=oebmTSxmq+zU8Utjs0yaAqanKgzPEsj+GJBxRd8logo=; b=GB52kiMK6/S3w6vS2fgJ7xzMw/+7AMiBKdvKnwg83l8zcEgwXMX9WBggKZnedPrN5F PdIGyi1FQDXxhOktvx2zPv5aQ9Kl131g1gIlguMkNZB5e7fdmm6Rdv3tqIWSZCSlSfHS Z56APPs15l9XKEiCWg8+6MUXyyoltkidbUfIDs10DV8Vs8gu/tLbXRNGKwwZMnSoSmus n6C1+X5iK8h3TrtrbkTU3BDL0JCQhx7+Fz15xt6fzj2Ptg4LX2NUnsYjkjpUgc1kLl9d L+o87eewuJyqOWR4EzYr/3dgG9YxyyxfXoF9DfQxRQ7fvWbbdtfMAcuGG+Il+NZh1Q8B CEwg== X-Gm-Message-State: AOAM533ui1AfT7XAdCeuxSkVk68yYBrH+n5Wkx3J/j6OfT4nxGwy99vB gyAbiduGMUlxoTbfk5J/azzu7w== X-Received: by 2002:a37:a40e:: with SMTP id n14mr12925505qke.81.1633395862031; Mon, 04 Oct 2021 18:04:22 -0700 (PDT) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id c9sm10444214qte.16.2021.10.04.18.04.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Oct 2021 18:04:21 -0700 (PDT) Date: Mon, 04 Oct 2021 18:04:21 -0700 (PDT) X-Google-Original-Date: Mon, 04 Oct 2021 18:04:17 PDT (-0700) Subject: Re: [PATCH v2 0/2] riscv: improve unaligned memory accesses In-Reply-To: <20210918221713.289f63bb@xhacker> CC: wangkefeng.wang@huawei.com, chenhuang5@huawei.com, Paul Walmsley , aou@eecs.berkeley.edu, Darius Rad , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org From: Palmer Dabbelt To: jszhang3@mail.ustc.edu.cn Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 18 Sep 2021 07:17:13 PDT (-0700), jszhang3@mail.ustc.edu.cn wrote: > On Sat, 18 Sep 2021 09:14:05 +0800 > Kefeng Wang wrote: > >> On 2021/9/17 22:14, Jisheng Zhang wrote: >> > On Thu, 16 Sep 2021 13:08:53 +0000 >> > Chen Huang wrote: >> > >> >> The patchset improves RISCV unaligned memory accesses, selects >> >> HAVE_EFFICIENT_UNALIGNED_ACCESS if CPU_HAS_NO_UNALIGNED not >> >> enabled and supports DCACHE_WORD_ACCESS to improve the efficiency >> >> of unaligned memory accesses. >> >> >> >> If CPU don't support unaligned memory accesses for now, please >> >> select CONFIG_CPU_HAS_NO_UNALIGNED. For I don't know which CPU >> >> don't support unaligned memory accesses, I don't choose the >> >> CONFIG for them. >> > This will break unified kernel Image for riscv. Obviously, we will have >> > two images for efficient unaligned access platforms and non-efficient >> > unaligned access platforms. IMHO, we may need alternative mechanism or >> > something else to dynamically enable related code path. >> >> it won't break unified kernel Image for riscv, if one SoC choose >> >> CPU_HAS_NO_UNALIGNED, the single Image won't support unaligned memory > > the "unified" means the kernel Image has to support all RV64GC or RV32GC SoCs. > To make the Image works for both efficient unaligned access and inefficient > unaligned access, I think we'd better make "inefficient unaligned access" > default behavior, the use alternative etc. tech to patch related code path > for efficient unaligned access. I agree, at least until we have a sufficient breadth of implementations to know whether efficient unaligned accesses are going to be possible. There was also a question about what exactly the C906 unaligned access handling looks like on GCC, as well. Do you guys have any sort of pipeline description? > > >> >> accesses, indeed, it depends on the CONFIG, and now, arm/powerpc/m68k has > > linux Distributions doesn't have enough background of which config options > must be enabled. I wouldn't be opposed to adding this as a Kconfig option, something along the lines of "tune for fast unaligned accesses" or whatever. I get that we're sort of just punting the problem to distros, but we could add a Kconfig.socs-like (though that is a mess, so we'd need something saner) tune target (which is maybe coupled to -mtune, as well?). That would a least let us give users the option of making this choice, and while it'd still likely be best to set this to slow unaligned accesse to start we may be able to more easily see what distros choose at this point. > >> >> similar configuration. > > I have little knowledge of powerpc or m68k, but there are serveral different > defconfig files for arm, for example multi_v7_defconfig and multi_v5_defconfig. > The previous v7 version enables HAVE_EFFICIENT_UNALIGNED_ACCESS while > the later v5 doesn't. Will you persuade riscv maintainers to accept one more > defconfig file? I'm not super worried about having more defconfigs, but I'm not really sure it's worth it for this option alone. > > Thanks > >> >> Yes,  it could be an optimization via alternative mechanism or something >> else to >> >> dynamically enable related code path later. >> >> > >> > Regards >> > >> >> Changes since v1: >> >> - As Darius Rad and Jisheng Zhang mentioned, some CPUs don't support >> >> unaligned memory accesses, add an option for CPUs to choose it or not. >> >> >> >> Chen Huang (2): >> >> riscv: support HAVE_EFFICIENT_UNALIGNED_ACCESS >> >> riscv: Support DCACHE_WORD_ACCESS >> >> >> >> arch/riscv/Kconfig | 5 ++++ >> >> arch/riscv/include/asm/word-at-a-time.h | 37 +++++++++++++++++++++++++ >> >> 2 files changed, 42 insertions(+) >> >> >> > >> > . >> >