Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3967956ybz; Mon, 20 Apr 2020 12:53:54 -0700 (PDT) X-Google-Smtp-Source: APiQypJh08DWq7yGzJtpfkDx+4e2qPM7AHlKTw9BBND746Gw7VIKE/b1SX8aRjZvlXem4EcKzmPS X-Received: by 2002:a17:906:7f0d:: with SMTP id d13mr18056900ejr.312.1587412433995; Mon, 20 Apr 2020 12:53:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587412433; cv=none; d=google.com; s=arc-20160816; b=OwMVYxuRJbW2habRKnFLZfRPf2RfUXDr3otat5Ztc5PFk+7PNKoRjLqVZXiEtsq7c/ my2a0ZODSYAeaGQxUNCLxdDX2Oi7XO7JyRuXqDmMKoPnbv2KH4iEoOqUCyt0yXmgm2+0 r3sYg6J/OVnsGfJol0YBT/P5SUWJe9uMVl0IZ/oKxUs2EEK7e+x3Ry++qsw0zycVtK1l 6AWbG6oTRmTtnhkZ407LxhWdefYiiVUuo8OoII1GeLtTE7kSu9MklVx2jBfrTD/z9w80 XYtbghs/jPrHPAvhsTBv96KAYlshKQmuPYk3k4z7YxbGDo5GBsRsmIG+1GaLHtw8K4xu sSgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date; bh=iuBbzIYD7Io0uI6o854adY47D8NoEJFgbYt7CmMovtM=; b=PLWMIAqBiYhy8215/NcFrXLTac0Yvu7Y2KY2841FzPwhVQUMEikhJ+H7goWK8Gj6A8 TJm5KdEipvBpBiuQunNxhpwrfM2SaN9chunacVL2wtf3JHP9KKXgbCBy9Z+ahaYHfHgk 7iUvkDCT8bAw8NK+o4b0QpaILHepgBlDqndY9PP3lBMwgBmqEomSWo7WYFgUq+ewdybs sElZeGaWgthurc003CW4+chxaL2ts6okx/YKy4zwhOP5YwiXcjS83pAuNw+Fv7KM6rts QlubFfO2GDMP/9ytV1GyMTNfViwQ0HRvJsBLQ3YRL4MWjbOBYfZw8xeo1kzf2+bGNq+N imIQ== 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 z12si322783edp.162.2020.04.20.12.53.31; Mon, 20 Apr 2020 12:53:53 -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 S1727027AbgDTTvo (ORCPT + 99 others); Mon, 20 Apr 2020 15:51:44 -0400 Received: from mx2.suse.de ([195.135.220.15]:59880 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726109AbgDTTvn (ORCPT ); Mon, 20 Apr 2020 15:51:43 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 42D0CAC20; Mon, 20 Apr 2020 19:51:41 +0000 (UTC) Date: Mon, 20 Apr 2020 12:48:13 -0700 From: Davidlohr Bueso To: Michel Lespinasse Cc: Andrew Morton , linux-mm , LKML , Peter Zijlstra , Laurent Dufour , Vlastimil Babka , Matthew Wilcox , Liam Howlett , Jerome Glisse , David Rientjes , Hugh Dickins , Ying Han , Jason Gunthorpe , Daniel Jordan Subject: Re: [PATCH v4 01/10] mmap locking API: initial implementation as rwsem wrappers Message-ID: <20200420194813.v7m7tmqhuza6qzoi@linux-p48b> Mail-Followup-To: Michel Lespinasse , Andrew Morton , linux-mm , LKML , Peter Zijlstra , Laurent Dufour , Vlastimil Babka , Matthew Wilcox , Liam Howlett , Jerome Glisse , David Rientjes , Hugh Dickins , Ying Han , Jason Gunthorpe , Daniel Jordan References: <20200415004353.130248-1-walken@google.com> <20200415004353.130248-2-walken@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200415004353.130248-2-walken@google.com> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 14 Apr 2020, Michel Lespinasse wrote: >This change wraps the existing mmap_sem related rwsem calls into a new >mmap locking API. There are two justifications for the new API: > >- At first, it provides an easy hooking point to instrument mmap_sem > locking latencies independently of any other rwsems. > >- In the future, it may be a starting point for replacing the rwsem > implementation with a different one, such as range locks. > >Signed-off-by: Michel Lespinasse >Reviewed-by: Daniel Jordan Reviewed-by: Davidlohr Bueso With one observation below. >+static inline void mmap_downgrade_write_lock(struct mm_struct *mm) >+{ >+ downgrade_write(&mm->mmap_sem); >+} Shouldn't this really be just mmap_downgrade_write()? In locking normally don't add the _lock at the end as it implies the operation of acquiring the lock. Thanks, Davidlohr