Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp4110693ybe; Mon, 16 Sep 2019 06:57:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqz62FMGAfULAme3NPIbl/XJOSd7FYQDQ2luHoqeh89jjyNN4SXNQlnUjgJ5Vn5TQFd3YAUZ X-Received: by 2002:a17:906:b204:: with SMTP id p4mr94415ejz.185.1568642220630; Mon, 16 Sep 2019 06:57:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568642220; cv=none; d=google.com; s=arc-20160816; b=aoPsLHiLxKAgIV9uHKU34OMIn7Ps3R39SBHvGP8ANI1rBkcnPoV/ENg1+9wf0ARzHZ 3httNm4EnIIUJ0OWW6XWNtYE91ntJTkhdOuEN210hmuTCSDShvEXrtJjuhUEdwyHb6pP UoO//wX+UT/U/LuF2f0DCzqykx7xql1am23s6WsoF9Q2jk/F3Cq4K5P0qFHCgCzPPxO4 XDC0JoWN2ssxSOqO7gheGqn102tmlJsuuYtC5Pt4WzG4Y+7J/P48hwa9LpqHaJodDzGu pZ14a6W8oPuY4pKN4BuyEqaIO+F56+t2VJT865DHWjfbzV/XtpDU9EIM1w6qHSNFJAm7 9HeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:to:subject; bh=L0pfR4UAyTTNYLr3YE9CVOmK9C02PUHWHno063v227I=; b=1BoYJ3Bs3b10hCjvkMLNgmcgmAEUAMzZeV6sdHqhLtOcmZdzoVWSmOqNlaizn0JWuQ Zl+rFkA+OimlPsZjx9zfIU0ps4y8eP40GqHdXO0s1RiFi2g3ap7qw45m6sl915jMvaEv fG9+7V9er4GdzWbRuvpBVrnzPB/nWNLHxgohpgPkeJg1sxjsc6nyGUWi5LYikr0gdXLD HGWebHrMI84Kw+lw5r4fh+M03IIqTsH39Yo9E6kmQ0zlVjB65dUVM+9TgV2QuPn6xsft z1KrAhelmsEXkSnAh6orgItIg+8zMeQVq6dSUf05807+VNPVtpRAAT9YS3wW11K1c60u mR+A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l5si18347036ejc.23.2019.09.16.06.56.35; Mon, 16 Sep 2019 06:57:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387826AbfIPNxp (ORCPT + 99 others); Mon, 16 Sep 2019 09:53:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59146 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387682AbfIPNxp (ORCPT ); Mon, 16 Sep 2019 09:53:45 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B486318C4276; Mon, 16 Sep 2019 13:53:44 +0000 (UTC) Received: from llong.remote.csb (dhcp-17-160.bos.redhat.com [10.18.17.160]) by smtp.corp.redhat.com (Postfix) with ESMTP id A5DA617F85; Mon, 16 Sep 2019 13:53:43 +0000 (UTC) Subject: Re: [PATCH 5/5] hugetlbfs: Limit wait time when trying to share huge PMD To: Matthew Wilcox , Mike Kravetz , Peter Zijlstra , Ingo Molnar , Will Deacon , Alexander Viro , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org References: <20190911150537.19527-1-longman@redhat.com> <20190911150537.19527-6-longman@redhat.com> <20190912034143.GJ29434@bombadil.infradead.org> <20190912044002.xp3c7jbpbmq4dbz6@linux-p48b> From: Waiman Long Organization: Red Hat Message-ID: Date: Mon, 16 Sep 2019 09:53:43 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190912044002.xp3c7jbpbmq4dbz6@linux-p48b> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.62]); Mon, 16 Sep 2019 13:53:45 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/12/19 12:40 AM, Davidlohr Bueso wrote: > > I also think that the right solution is within the mm instead of adding > a new api to rwsem and the extra complexity/overhead to osq _just_ for > this > case. We've managed to not need timeout extensions in our locking > primitives > thus far, which is a good thing imo. Adding a variant with timeout can be useful in resolving some potential deadlock issues found by lockdep. Anyway, there were talk about merging rt-mutex and regular mutex in the LPC last week. So we will need to have mutex_lock() variant with timeout for that to happen. Cheers, Longman