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=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 D7314C43603 for ; Tue, 17 Dec 2019 09:31:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A195F207FF for ; Tue, 17 Dec 2019 09:31:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A195F207FF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3A89D8E004C; Tue, 17 Dec 2019 04:31:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 359348E0040; Tue, 17 Dec 2019 04:31:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 297068E004C; Tue, 17 Dec 2019 04:31:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0239.hostedemail.com [216.40.44.239]) by kanga.kvack.org (Postfix) with ESMTP id 1503D8E0040 for ; Tue, 17 Dec 2019 04:31:46 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id B6346180AD806 for ; Tue, 17 Dec 2019 09:31:45 +0000 (UTC) X-FDA: 76274116170.29.dad16_f54ba4374e04 X-HE-Tag: dad16_f54ba4374e04 X-Filterd-Recvd-Size: 3827 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Tue, 17 Dec 2019 09:31:45 +0000 (UTC) Received: by mail-wm1-f66.google.com with SMTP id p17so2280218wmb.0 for ; Tue, 17 Dec 2019 01:31:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=jCNLk3ysTa7drVwjPrE0QpXknGVHoz5c/ceSyho58q8=; b=iw6l7MnZ8GNFdeB13deo0tDCo+RMQq4NDy/L8KZa3R9Ha/4tkE3qP9Y7x/0Svb8dnx cGmz29/yuP3RrCKJ06TOEuUmPkB5M3Qq1KgemqhB8qKntMXppyC7vro6sj4zqWrfSxGw KPan25CtKO360w0YZWIJzP6v3oRaaltl2mTNWd6N3UVpuHkPU793R7YHmwGw+4rwZXYT Iq2RhMebkoYh8+GA0d0DiuaTEmqbl9M638qGAvhOoln7PPNsUOeQJOp97iKaZDSWh2Pd JHNX9VVqdy3lkCLIPCchM8pTEkJYi1E7UUS/aMdZRfjp/ttUPVRDeSi4O1f1IH3Yt5vo fDBA== X-Gm-Message-State: APjAAAUcT4PM4v5LPCrg9B4jp5eUEThpCljZd7P7GP67nPzU82cJWFkz xxIsydBEGqhkXbfdDHDcTLc= X-Google-Smtp-Source: APXvYqxB4qae84Gbted6ihgN3WcOBe6ZO2qabJbzOA2Q1KbNDFu7kMHAinnSOV2FdCilwtV/hdYduA== X-Received: by 2002:a1c:4d18:: with SMTP id o24mr4237266wmh.35.1576575104198; Tue, 17 Dec 2019 01:31:44 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id h66sm2467362wme.41.2019.12.17.01.31.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Dec 2019 01:31:43 -0800 (PST) Date: Tue, 17 Dec 2019 10:31:43 +0100 From: Michal Hocko To: Waiman Long Cc: Mike Kravetz , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Matthew Wilcox , Davidlohr Bueso , Andi Kleen , "Aneesh Kumar K.V" Subject: Re: [PATCH v2] mm/hugetlb: Defer freeing of huge pages if in non-task context Message-ID: <20191217093143.GC31063@dhcp22.suse.cz> References: <20191217012508.31495-1-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191217012508.31495-1-longman@redhat.com> User-Agent: Mutt/1.12.2 (2019-09-21) 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 Mon 16-12-19 20:25:08, Waiman Long wrote: [...] > Both the hugetbl_lock and the subpool lock can be acquired in > free_huge_page(). One way to solve the problem is to make both locks > irq-safe. Please document why we do not take this, quite natural path and instead we have to come up with an elaborate way instead. I believe the primary motivation is that some operations under those locks are quite expensive. Please add that to the changelog and ideally to the code as well. We probably want to fix those anyway and then this would be a temporary workaround. > Another alternative is to defer the freeing to a workqueue job. > > This patch implements the deferred freeing by adding a > free_hpage_workfn() work function to do the actual freeing. The > free_huge_page() call in a non-task context saves the page to be freed > in the hpage_freelist linked list in a lockless manner. Do we need to over complicate this (presumably) rare event by a lockless algorithm? Why cannot we use a dedicated spin lock for for the linked list manipulation? This should be really a trivial code without an additional burden of all the lockless subtleties. > + pr_debug("HugeTLB: free_hpage_workfn() frees %d huge page(s)\n", cnt); Why do we need the debugging message here? -- Michal Hocko SUSE Labs