Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3508581pxf; Mon, 29 Mar 2021 04:21:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwMczDqeRAl5buIZIZE+187dqdYGscHXWnjYHRgbIHbHX6ftgunUxdavCChLJsBlwVsH0DT X-Received: by 2002:a17:906:1706:: with SMTP id c6mr28596024eje.223.1617016889293; Mon, 29 Mar 2021 04:21:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617016889; cv=none; d=google.com; s=arc-20160816; b=qmoQZK1ViBvMlwoYka01bL2Myl3f7yzR6X/M8N9i57tWyBjDRZNLnRy4XaylZ8tgyG e3zu8XmVhXlLcYUqY1uG5kLcBYzdPUFjNkSYmpFtq//+YsboCpz7B2lNt8Y95RuWqwM8 xqiiOS+5pT5TAPRJpnRS7ZGK4JJwASKskSeomYvsuSo/Ih7SDl6Yk6ooY2KCQX9ChHQ6 d8493I00uGZG6n1P0FLA7dfWy6FX64Q7eaSB9nxQQO2EmOtstmS4QJ/VTuQ4lkaof6lX 9ilsYwFdHZ9zFYdfdk6ibPsjGVFc7GAmdYt6CXq2uc7CNnNbs0/63LlQim3UQTTtnAH4 XYbw== 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=OFWxnq0LnXY61+W6HxpmooHoG1B3GvhULY2DjR1lvcQ=; b=YiJingxlx1tBNLHSNinaSOyh0tLa73XY0lEBWHeNPVzDoRLDh4Pcgq0BdFZF29kTKx TBMbZwj4Z59xVmgpVO3L02ex24Je0wgXp3fcO0NrH8nYiHOR40TkC0qVF+EU64NzaQI1 CE1fp/yx0/4nUf6ffgn3T/9Ykf3aZgghbIksvb2exaTMA9d20z6ijS2GRt4MxXoTzNcf s5ySHgVE6lRBnGnh5fd/Ww1Umn0Q0CVVIvAXosQ4z4qAoEAetpKuy79fT+GP8Eu17rQW x2zC7HeHrSubkznjoKvdgkCUS58K/Uwspwr3jxmVS3Khejy6nYCnnpMJWizeoBUuDdcX 7ZYw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=VkTFoEy2; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ly21si12763631ejb.128.2021.03.29.04.21.07; Mon, 29 Mar 2021 04:21:29 -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=@kernel.org header.s=k20201202 header.b=VkTFoEy2; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232239AbhC2LUJ (ORCPT + 99 others); Mon, 29 Mar 2021 07:20:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:54130 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231726AbhC2LTn (ORCPT ); Mon, 29 Mar 2021 07:19:43 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 8FD766193A; Mon, 29 Mar 2021 11:19:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617016782; bh=j7SIgfFWVMLoa2fKOiGrGvajt0FjTnG/iQTsS4gCWqk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=VkTFoEy2moVtohhFfxYKcRZGdY9J2izAqu/m9Z+qifrntBWsoS4luLMma+IXXWdcA Ia0FqVi4ANgsnIwlPaNNVTJpibPgtgBbHG4I2zHS/58G/1VTuZ3mfJRhpR9NEBsFQG 3RmlTKX1lxZLJ/Yuy53lL0gTED5bwGmrCXGRR6kQ5Db+JEl5Rm/w9VajmdUZljD7iB hzDz/ESGJmCzXDIjsOrJRmV8s7Nm6yu8JWxJifYSZzwpJVip9sPNq21CmLzunLXzEu c+nrjP2Q+c8/IxdXtOo9CeTZ+aRnzhLzYdHe35Uc6RBn4m4V0zpnxSzimjs8a0NMZ6 qhSS6ufPG+/wA== Received: by mail-lj1-f172.google.com with SMTP id u20so15407921lja.13; Mon, 29 Mar 2021 04:19:42 -0700 (PDT) X-Gm-Message-State: AOAM531/CFHooc1bqg8wJTR9XTeoiCeuEfxe0aVUoZBaojeG32Eh9Vga VGlI8raVWxgab3G8fyfwVMHaI/kUhtbKpOJIaKY= X-Received: by 2002:a2e:994e:: with SMTP id r14mr17623961ljj.115.1617016780900; Mon, 29 Mar 2021 04:19:40 -0700 (PDT) MIME-Version: 1.0 References: <1616868399-82848-1-git-send-email-guoren@kernel.org> <1616868399-82848-4-git-send-email-guoren@kernel.org> In-Reply-To: From: Guo Ren Date: Mon, 29 Mar 2021 19:19:29 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 3/4] locking/qspinlock: Add ARCH_USE_QUEUED_SPINLOCKS_XCHG32 To: Peter Zijlstra Cc: linux-riscv , Linux Kernel Mailing List , linux-csky@vger.kernel.org, linux-arch , Guo Ren , Will Deacon , Ingo Molnar , Waiman Long , Arnd Bergmann , Anup Patel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 29, 2021 at 3:50 PM Peter Zijlstra wrote: > > On Sat, Mar 27, 2021 at 06:06:38PM +0000, guoren@kernel.org wrote: > > From: Guo Ren > > > > Some architectures don't have sub-word swap atomic instruction, > > they only have the full word's one. > > > > The sub-word swap only improve the performance when: > > NR_CPUS < 16K > > * 0- 7: locked byte > > * 8: pending > > * 9-15: not used > > * 16-17: tail index > > * 18-31: tail cpu (+1) > > > > The 9-15 bits are wasted to use xchg16 in xchg_tail. > > > > Please let architecture select xchg16/xchg32 to implement > > xchg_tail. > > So I really don't like this, this pushes complexity into the generic > code for something that's really not needed. > > Lots of RISC already implement sub-word atomics using word ll/sc. > Obviously they're not sharing code like they should be :/ See for > example arch/mips/kernel/cmpxchg.c. I see, we've done two versions of this: - Using cmpxchg codes from MIPS by Michael - Re-write with assembly codes by Guo But using the full-word atomic xchg instructions implement xchg16 has the semantic risk for atomic operations. I don't think export xchg16 in a none-sub-word atomic machine is correct. > > Also, I really do think doing ticket locks first is a far more sensible > step. NACK by Anup -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/