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 X-Spam-Level: X-Spam-Status: No, score=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97ED5C4320E for ; Mon, 23 Aug 2021 08:15:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7C2B161371 for ; Mon, 23 Aug 2021 08:15:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235656AbhHWIPp (ORCPT ); Mon, 23 Aug 2021 04:15:45 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:57029 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235577AbhHWIPg (ORCPT ); Mon, 23 Aug 2021 04:15:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1629706494; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sAS3UII3BoCLendYghwp+E5/qpLsis2DFPR6GELCxPg=; b=RnAGNa8Y6XFvGjWAbaBJfkItKTTh9aOxzk9WYYcSjv+OQpxMG21ktfBN6TE1kwsuIDsfgZ msBBND6ayBdF8uYhHs0Wq0Cmv1t5GFhy1UOQ7KiodjZM94idFAOwHzgEpWv0mQxv+lRiRf OP4igU/iumDw+iw+F1hgdZ6leJeEak4= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-558-SEZA6p8MNsqw-LEyo3JS2g-1; Mon, 23 Aug 2021 04:14:53 -0400 X-MC-Unique: SEZA6p8MNsqw-LEyo3JS2g-1 Received: by mail-wr1-f71.google.com with SMTP id m2-20020a0560000082b0290154f6e2e51fso4859473wrx.12 for ; Mon, 23 Aug 2021 01:14:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:organization:user-agent:mime-version :content-transfer-encoding; bh=sAS3UII3BoCLendYghwp+E5/qpLsis2DFPR6GELCxPg=; b=MLcINxaXt9aGHWwYh6Vwwmn1/ySE+6+XvULfurAbxAa6OmIPbG34/K4W/qzEiuQrlj QRTWZoBswRTihHd9Bg+G7sdQ3GwNI2BJfsCzAuBnzZWUiYMdDB+LkNuLTnJB2O5uM3IM PkTuf2QSDYLW1wobsT3uzt2OQhUgNqyMjLGbSZe4mLx6fEHtRqQ1UqJo4Tl+NG5mozqx NmTf6AoE/HgQVpf85lISe7KQSBqh7P/ME+V2f5uTXX5VTXWjcHjXZFH7JJ8atz2aEtJu FhqPl4qa8kjOuo0XIo0HwWMOQAmLd4pPZhBkZLvAG/rGHHa/kY2RNd+key/xRSt1JR6x ulpg== X-Gm-Message-State: AOAM530/COLia+a71auYBfl/T7y4HR/zeLUV6lksIDnpmSJ+iut1lV+M kdjVqF7L/WTinihQK/qQ0vN+F2yygZ0esnXMMlLyefgZC0BTjq1ybtTiVYV2BFLsJ5eXPZtY5mo B0R/l/wfddpfkIuEynG8Q6NRR X-Received: by 2002:adf:e910:: with SMTP id f16mr6700306wrm.393.1629706491883; Mon, 23 Aug 2021 01:14:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx9tWYyiX6YvxpM93MetANrNoX2lZvyAZMJH8SnDUJVD31ZiO7K1OFWJvibdiL9k2vCA5llew== X-Received: by 2002:adf:e910:: with SMTP id f16mr6700299wrm.393.1629706491736; Mon, 23 Aug 2021 01:14:51 -0700 (PDT) Received: from 0.7.3.c.2.b.0.0.0.3.7.8.9.5.0.2.0.0.0.0.a.d.f.f.0.b.8.0.1.0.0.2.ip6.arpa (0.7.3.c.2.b.0.0.0.3.7.8.9.5.0.2.0.0.0.0.a.d.f.f.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:ffda:0:2059:8730:b2:c370]) by smtp.gmail.com with ESMTPSA id f2sm14085343wru.31.2021.08.23.01.14.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Aug 2021 01:14:51 -0700 (PDT) Message-ID: <8e2ab23b93c96248b7c253dc3ea2007f5244adee.camel@redhat.com> Subject: Re: [Cluster-devel] [PATCH v6 10/19] gfs2: Introduce flag for glock holder auto-demotion From: Steven Whitehouse To: Andreas Gruenbacher , Bob Peterson Cc: Linus Torvalds , Alexander Viro , Christoph Hellwig , "Darrick J. Wong" , Jan Kara , LKML , Matthew Wilcox , cluster-devel , linux-fsdevel , ocfs2-devel@oss.oracle.com Date: Mon, 23 Aug 2021 09:14:50 +0100 In-Reply-To: References: <20210819194102.1491495-1-agruenba@redhat.com> <20210819194102.1491495-11-agruenba@redhat.com> <5e8a20a8d45043e88013c6004636eae5dadc9be3.camel@redhat.com> Organization: Red Hat UK Ltd Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2021-08-20 at 17:22 +0200, Andreas Gruenbacher wrote: > On Fri, Aug 20, 2021 at 3:11 PM Bob Peterson > wrote: > > [snip] > > > > You can almost think of this as a performance enhancement. This > > concept > > allows a process to hold a glock for much longer periods of time, > > at a > > lower priority, for example, when gfs2_file_read_iter needs to hold > > the > > glock for very long-running iterative reads. > > Consider a process that allocates a somewhat large buffer and reads > into it in chunks that are not page aligned. The buffer initially > won't be faulted in, so we fault in the first chunk and write into > it. > Then, when reading the second chunk, we find that the first page of > the second chunk is already present. We fill it, set the > HIF_MAY_DEMOTE flag, fault in more pages, and clear the > HIF_MAY_DEMOTE > flag. If we then still have the glock (which is very likely), we > resume the read. Otherwise, we return a short result. > > Thanks, > Andreas > If the goal here is just to allow the glock to be held for a longer period of time, but with occasional interruptions to prevent starvation, then we have a potential model for this. There is cond_resched_lock() which does this for spin locks. So perhaps we might do something similar: /** * gfs2_glock_cond_regain - Conditionally drop and regain glock * @gl: The glock * @gh: A granted holder for the glock * * If there is a pending demote request for this glock, drop and * requeue a lock request for this glock. If there is no pending * demote request, this is a no-op. In either case the glock is * held on both entry and exit. * * Returns: 0 if no pending demote, 1 if lock dropped and regained */ int gfs2_glock_cond_regain(struct gfs2_glock *gl, struct gfs2_holder *gh); That seems more easily understood, and clearly documents places where the lock may be dropped and regained. I think that the implementation should be simpler and cleaner, compared with the current proposed patch. There are only two bit flags related to pending demotes, for example, so the check should be trivial. It may need a few changes depending on the exact circumstances, but hopefully that illustrates the concept, Steve.