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=-5.8 required=3.0 tests=BAYES_00,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 F00C1C433C1 for ; Mon, 22 Mar 2021 14:42:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 55E636191C for ; Mon, 22 Mar 2021 14:42:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 55E636191C Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DE9AD6B00DA; Mon, 22 Mar 2021 10:23:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D98916B00DC; Mon, 22 Mar 2021 10:23:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C39E26B00DD; Mon, 22 Mar 2021 10:23:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0056.hostedemail.com [216.40.44.56]) by kanga.kvack.org (Postfix) with ESMTP id A7FBB6B00DA for ; Mon, 22 Mar 2021 10:23:56 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 1794A1802EFE9 for ; Mon, 22 Mar 2021 14:42:47 +0000 (UTC) X-FDA: 77947776774.07.CAD00C5 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf26.hostedemail.com (Postfix) with ESMTP id 079874080F7C for ; Mon, 22 Mar 2021 14:42:38 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1616424147; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qE0A1N7/F7ncLf984ovqgJKYsAY3yE04wS+vinpzFio=; b=r2N4CanunEnJFd1mm3gd/ItVBlnWonx5pC0IRjlo/fHZvc5DU9RITCU5X+6U+D5tL2gpj3 6u7stEgpGh0zbOmfbJGnJHPslt4ZCskJ04e16QDYxQxHiRPuNVqlXoYOVckRykomSLgWnf 36rOF0eVyh6c+Yr9f8HeuLcefZ9h+Ns= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 9E22FAD4A; Mon, 22 Mar 2021 14:42:27 +0000 (UTC) Date: Mon, 22 Mar 2021 15:42:26 +0100 From: Michal Hocko To: Mike Kravetz Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Shakeel Butt , Oscar Salvador , David Hildenbrand , Muchun Song , David Rientjes , Miaohe Lin , Peter Zijlstra , Matthew Wilcox , HORIGUCHI NAOYA , "Aneesh Kumar K . V" , Waiman Long , Peter Xu , Mina Almasry , Andrew Morton Subject: Re: [RFC PATCH 7/8] hugetlb: add update_and_free_page_no_sleep for irq context Message-ID: References: <20210319224209.150047-1-mike.kravetz@oracle.com> <20210319224209.150047-8-mike.kravetz@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210319224209.150047-8-mike.kravetz@oracle.com> X-Stat-Signature: mjdhii6ppsrteaj4a3roesgnxqnr941a X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 079874080F7C Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf26; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616424158-499246 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri 19-03-21 15:42:08, Mike Kravetz wrote: > The locks acquired in free_huge_page are irq safe. However, in certain > circumstances the routine update_and_free_page could sleep. Since > free_huge_page can be called from any context, it can not sleep. > > Use a waitqueue to defer freeing of pages if the operation may sleep. A > new routine update_and_free_page_no_sleep provides this functionality > and is only called from free_huge_page. > > Note that any 'pages' sent to the workqueue for deferred freeing have > already been removed from the hugetlb subsystem. What is actually > deferred is returning those base pages to the low level allocator. This patch or its alternative would need to be applied prior to patch 6 which makes the whole context IRQ safe. Besides that the changelog doesn't really say anything about changed user visible behavior change. Now if somebody decreases the GB huge pool from the userspace the real effect on the freed up memory will be postponed to some later time. That "later" is unpredictable as it depends on WQ utilization. We definitely need some sort of wait_for_inflight pages. One way to do that would be to have a dedicated WQ and schedule a sync work item after the pool has been shrunk and wait for that item. -- Michal Hocko SUSE Labs