Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp491068ybk; Wed, 20 May 2020 04:59:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLpUPifoqcaMD9ug5bkcvdSd85sXuEG6p3889fo+k1yVQ2uJo4MBHlPeC8SmleQL8sMewy X-Received: by 2002:a05:6402:1bc1:: with SMTP id ch1mr3145606edb.90.1589975979627; Wed, 20 May 2020 04:59:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589975979; cv=none; d=google.com; s=arc-20160816; b=Tl+oqaaj0HNc/xKPh7h7ZPOqW4nVfkB4VHtECBJE5qm8nN8IzU69poI0SzMTJwdL1c ruPN90po3kEFYK9rWZXnyktSu4wbJ94260B9u/pR1+HOdV+A5PDvHPUOSb2wkv1pQ+bc LbOH8u4+MIrMv6LLxNRYSwAg24g6CPuoEznarCC/7LiunwieGirddjNdhFrRuTAzHNfR zEMnajMJtc7SN4LyXVk/UtK7fz7TB9cpbZeQHZibIQaIyhSHTRFnU3/7eJzSBnpwk/2R 9Vrs0fncFYT1nGS0rOFWCDy6DMOjjkrCRWHWFEyyPKIEM7nTbtaRDnz5Ib8ELmUDVsWp UNAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=NcVezUgkB1wJX3ibQfvrj5yaQVr4UIXA0UUXTXh+bwk=; b=swEGcYNTllEzAnGV+usYXvyocnLX4GJWPtF9SAAKbwSv6BUYHTLcb50d1tzYstkd6d PNry9Tsn/T5xu/Vez8z2V2/kxRM8S4MYFcOouN8SbQbFCyfaad55f/C05Hftb9bFeh0D y0SGtIETYX8TIaM+5Zb7bzqFW+U00WAUVEeeWnJGJuNhj7BfoZplvyJ2HtdCDp/yFV5x 54M2Trj+q7pmK5Bzazun6O8aM0dWLV1o6YjqFq7F9xpSkbV1eleNiJ+hcXI/7E08KYOS HEvtt4H0nf4TtD3QALmD2Da0pvtIYEnbmLRMr1f2WxCXdculTHP4CcrouvI9MHz7xyDR i0ww== ARC-Authentication-Results: i=1; mx.google.com; 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 ca23si1262941edb.359.2020.05.20.04.59.16; Wed, 20 May 2020 04:59:39 -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; 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 S1726812AbgETL5t (ORCPT + 99 others); Wed, 20 May 2020 07:57:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60752 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726443AbgETL5t (ORCPT ); Wed, 20 May 2020 07:57:49 -0400 Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3709FC061A0E for ; Wed, 20 May 2020 04:57:49 -0700 (PDT) Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1jbNLx-00071O-Su; Wed, 20 May 2020 13:57:42 +0200 Date: Wed, 20 May 2020 13:57:41 +0200 From: Sebastian Andrzej Siewior To: Song Bao Hua Cc: "linux-kernel@vger.kernel.org" , Peter Zijlstra , Ingo Molnar , Steven Rostedt , Will Deacon , Thomas Gleixner , "Paul E . McKenney" , Linus Torvalds , "Luis Claudio R. Goncalves" , Seth Jennings , Dan Streetman , Vitaly Wool , Andrew Morton , "linux-mm@kvack.org" , Linuxarm Subject: Re: [PATCH 8/8] mm/zswap: Use local lock to protect per-CPU data Message-ID: <20200520115741.wy2qnmauxmjtrrzj@linutronix.de> References: <20200519201912.1564477-1-bigeasy@linutronix.de> <20200519201912.1564477-9-bigeasy@linutronix.de> <20200520102634.pin4mzyytmfqtuo2@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-05-20 11:13:31 [+0000], Song Bao Hua wrote: > For example, on cpu1, once you begin to compress, you hold the percpu acomp-ctx and percpu destination buffer of CPU1, the below code makes sure you get the acomp and dstmem from the same core by disabling preemption with get_cpu_var and put_cpu_var: > dst = get_cpu_var(zswap_dstmem); > acomp_ctx = *this_cpu_ptr(entry->pool->acomp_ctx); > put_cpu_var(zswap_dstmem); > > then there are two cases: > > 1. after getting dst and acomp_ctx of cpu1, you might always work in cpu1, the mutex in per-cpu acomp-ctx will guarantee two compressions won't do at the same core in parallel, and it also makes certain compression and decompression won't do at the same core in parallel. Everything is like before. For readability I suggest not to mix per-CPU and per-CTX variables like that. If zswap_dstmem is protected by the mutex, please make it part of acomp_ctx. Sebastian