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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5DAD4C433F5 for ; Mon, 21 Mar 2022 15:22:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350111AbiCUPXw (ORCPT ); Mon, 21 Mar 2022 11:23:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53204 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350018AbiCUPWx (ORCPT ); Mon, 21 Mar 2022 11:22:53 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AAE754B1D9; Mon, 21 Mar 2022 08:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=yjHmNUrTcsfBaaW2FV8OWLDc9yEfNnCQ4g7zaOGPWqs=; b=pM6u9L8P999sXYeV/U2ZFRYDSN SpEi168deMKZu9jl3PQ2+oOchdAFGkGuEC8zT6guPBzxs5YkCKUmjvKUW9zwv8NvHCPKYaEiecS6t 7VDVjvBg6ESSZ7MQQSSqB+OuszsrOOcQ14kdJXG6liG6oe206cC7QFz1vnR8MkQVWicnRzRQGHMkm KVQrS63cEIfBON47cvlquRNC6Q8lsctQWTLO3kSRia4x42KS8uZKD+iflz4S52GmkYIpS8C1LJEWU frUF02UGLNlLqQ483T3LkqrTp9wKwK6BcXpsUOb61xFDTBMJAcp2KcnNDS6QpmMBXA2tqs1xBARiC FbIDCPkA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nWJqI-00Ah2w-Dv; Mon, 21 Mar 2022 15:21:10 +0000 Date: Mon, 21 Mar 2022 15:21:10 +0000 From: Matthew Wilcox To: JeffleXu Cc: dhowells@redhat.com, linux-cachefs@redhat.com, xiang@kernel.org, chao@kernel.org, linux-erofs@lists.ozlabs.org, torvalds@linux-foundation.org, gregkh@linuxfoundation.org, linux-fsdevel@vger.kernel.org, joseph.qi@linux.alibaba.com, bo.liu@linux.alibaba.com, tao.peng@linux.alibaba.com, gerry@linux.alibaba.com, eguan@linux.alibaba.com, linux-kernel@vger.kernel.org, luodaowen.backend@bytedance.com Subject: Re: [PATCH v5 03/22] cachefiles: introduce on-demand read mode Message-ID: References: <20220316131723.111553-1-jefflexu@linux.alibaba.com> <20220316131723.111553-4-jefflexu@linux.alibaba.com> <6bc551d2-15fc-5d17-c99b-8db588c6b671@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Mar 21, 2022 at 11:18:05PM +0800, JeffleXu wrote: > >> Besides, IMHO read-write lock shall be more performance friendly, since > >> most cases are the read side. > > > > That's almost never true. rwlocks are usually a bad idea because you > > still have to bounce the cacheline, so you replace lock contention > > (which you can see) with cacheline contention (which is harder to > > measure). And then you have questions about reader/writer fairness > > (should new readers queue behind a writer if there's one waiting, or > > should a steady stream of readers be able to hold a writer off > > indefinitely?) > > Interesting, I didn't notice it before. Thanks for explaining it. No problem. It's hard to notice. > BTW what I want is just > > ``` > PROCESS 1 PROCESS 2 > ========= ========= > #lock #lock > set DEAD state if (not DEAD) > flush xarray enqueue into xarray > #unlock #unlock > ``` > > I think it is a generic paradigm. So it seems that the spinlock inside > xarray is already adequate for this job? Absolutely; just use xa_lock() to protect both setting & testing the flag.