Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 21 Nov 2022 09:19:50 -0800
From:   Davidlohr Bueso <dave@stgolabs.net>
To:     Dan Williams <dan.j.williams@intel.com>
Cc:     ira.weiny@intel.com, Bjorn Helgaas <bhelgaas@google.com>,
        Gregory Price <gregory.price@memverge.com>,
        Jonathan Cameron <Jonathan.Cameron@huawei.com>,
        "Li, Ming" <ming4.li@intel.com>,
        Vishal Verma <vishal.l.verma@intel.com>,
        Lukas Wunner <lukas@wunner.de>,
        Alison Schofield <alison.schofield@intel.com>,
        linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI/DOE: Remove asynchronous task support
Message-ID: <20221121171950.yflx4nklyqtrhn7s@offworld>
References: <20221119222527.1799836-1-ira.weiny@intel.com>
 <637b98358f7d0_1ee2429488@dwillia2-mobl3.amr.corp.intel.com.notmuch>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <637b98358f7d0_1ee2429488@dwillia2-mobl3.amr.corp.intel.com.notmuch>
User-Agent: NeoMutt/20220429
Precedence: bulk

On Mon, 21 Nov 2022, Dan Williams wrote:

>The mutex will attempt to maintain fairness in its own waitqueue. If the
>current task in exec_task() sees PCI_DOE_FLAG_CANCEL, it will drop out
>and release the lock and then all waiters can check PCI_DOE_FLAG_CANCEL
>before exec_task().

Yes, and try-locking is hacky by nature. In addition, relying on the mutex
queuing will often be more optimal as it tries to avoid blocking altogether
via mcs (which is also cacheline friendly).

Thanks,
Davidlohr