From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EA7F6E728C9 for ; Fri, 29 Sep 2023 16:51:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=na6YeL1V18adBGf5g4fPRfs6hywy93R0SRPYtNBzrp0=; b=QK491n/CAu7v+Q G5UJP39XTA+fVzc25ITEBGbuSo8mEribN0MMniobuh9Z08WEyYJWvSjVzh01It0CTnhiOtOgz0LFd k9XzR4bghyKtvzISG3ySkjlV3k0Bh7UwMdY0RyoiZrAz6jtYCoFgE+aYfUsQU0QReGxlj9+hbBdXc fgCsTRtyb2UqJ7S6O1um9xs2h9z71WMfU+PkDXngpYahE9f+iZFL6iWXU6gr8eDjj/xUC922leIdZ fh9rN+yG/ozf+e8lqnH5Tp6mktM3ZNFz10eQS8yFsv4l/MV3iaMly2w5V9rM5MZkKLMcuxSeQp0OJ 4Z0o/nAAOdYOpGLAyuzQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qmGiA-008JN4-30; Fri, 29 Sep 2023 16:51:30 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qmGi8-008JMi-10 for linux-arm-kernel@lists.infradead.org; Fri, 29 Sep 2023 16:51:29 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id ABD87B81FE4; Fri, 29 Sep 2023 16:51:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C1766C433C8; Fri, 29 Sep 2023 16:51:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1696006286; bh=e+MfC4PIgCSeLTTVXRSQHMaGi9tLREqobU6WrhAe8BM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FNltngMjUr8VLepDFqGle3Z9vALXpPvejonC7+cHu4+WUQsufEUPfcsYmY59pjClS XhutP7m4ebpXvPV/jmK7ET7OptKm0HEzwoLcdwT8Tv2pnnBn9Ro2cK9Cyirn96Bpjb US1wnPrlhcorOB8Mtnv5O2cxNTBZvHS/j25N9T3hqmu6EkK6OjcxaENdBLLdaEt6Lx nLHZVh8vxaDXIoacXyXzNvKtrQdPjto/MR3o9QyLrGq1QI2Q7g6GmMS7C5v29GAYHr WzrTYF57OFFmIoCa6kI9A9MAyjK3rKqwG88KrFdZtXxWfWHXHVzXWz5WBRpJSZ8IJ/ W9ySjdMrcAG8Q== Date: Fri, 29 Sep 2023 17:51:21 +0100 From: Will Deacon To: Guo Hui Cc: catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, quic_jiles@quicinc.com, mark.rutland@arm.com, wangxiaohua@uniontech.com Subject: Re: [PATCH] arm64: mm: Optimize querying asid from reserved_asids Message-ID: <20230929165119.GA30869@willie-the-truck> References: <20230927055106.14635-1-guohui@uniontech.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230927055106.14635-1-guohui@uniontech.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230929_095128_504181_C5FB484F X-CRM114-Status: GOOD ( 21.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Sep 27, 2023 at 01:51:06PM +0800, Guo Hui wrote: > Move reserved_asids updates into function flush_context. When > asid_generation increases, reserved_asids are updated synchronously. > The execution frequency of function flush_context is far less than > that of function check_update_reserved_asid. In function > check_update_reserved_asid, you only need to query whether it is > in reserved_asids based on the new newasid, and there is no need > to update it. > > In the function check_update_reserved_asid, among all the times > reserved_asids are hit, the probability that newasid is equal to > the reserved_asids of the current CPU is about greater than 70%. Do you have any performance numbers to justify this change? > diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c > index 188197590fc9..76e0beb14466 100644 > --- a/arch/arm64/mm/context.c > +++ b/arch/arm64/mm/context.c > @@ -101,7 +101,7 @@ static void set_reserved_asid_bits(void) > #define asid_gen_match(asid) \ > (!(((asid) ^ atomic64_read(&asid_generation)) >> asid_bits)) > > -static void flush_context(void) > +static void flush_context(u64 generation) > { > int i; > u64 asid; > @@ -120,6 +120,8 @@ static void flush_context(void) > */ > if (asid == 0) > asid = per_cpu(reserved_asids, i); > + > + asid = generation | (asid & ~ASID_MASK); I'm struggling to see how this is safe with multiple rollovers. For example, if we have the following sequence of events on one CPU: 1. Task A runs with ASID 42 2. Context switch to Task C with ASID 66 3. A rollover occurs 4. Task B runs for the first time; gets allocated ASID 42 5. Another rollover occurs 6. Task A runs Won't task A get ASID 42, even though that's reserved for task B? But this code is subtle, so maybe I missed something. Also, if we change this, then you should update the TLA+ model over at https://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/kernel-tla.git/tree/asidalloc.tla Cheers, Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel