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 3C9A8C433E0 for ; Thu, 11 Mar 2021 09:46:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8C5CB64F4D for ; Thu, 11 Mar 2021 09:45:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C5CB64F4D 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 E93F78D02A5; Thu, 11 Mar 2021 04:45:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E6B208D028E; Thu, 11 Mar 2021 04:45:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D0F598D02A5; Thu, 11 Mar 2021 04:45:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0137.hostedemail.com [216.40.44.137]) by kanga.kvack.org (Postfix) with ESMTP id B1D448D028E for ; Thu, 11 Mar 2021 04:45:58 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7167E180ACF6C for ; Thu, 11 Mar 2021 09:45:58 +0000 (UTC) X-FDA: 77907111996.30.D7F4A25 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf25.hostedemail.com (Postfix) with ESMTP id 325666000106 for ; Thu, 11 Mar 2021 09:44:56 +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=1615455896; 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=hPGMgeu1sq1z6aVRCxKf0fbmN46tuuOHRNw/lUzEVpQ=; b=ATvk+YnYvkBs+GAbqbrri42v+ydF2YXmq9mRLrTFeI1bI5oL48J/nA4AiIwdNSMh7ZMKgI XNYd/qO8PVUOK3UBnwS6fkYek8Lh/uY58U3vHJ9UczcgfukHqSX5vPKxYmwUpI6dcd8RUL kx0ATR7BmwCQ2Fyh3e3vENW4kniVbjU= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B62AFAB8C; Thu, 11 Mar 2021 09:44:56 +0000 (UTC) Date: Thu, 11 Mar 2021 10:44:56 +0100 From: Michal Hocko To: Peter Zijlstra Cc: Mike Kravetz , linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Paul E . McKenney" , Shakeel Butt , tglx@linutronix.de, john.ogness@linutronix.de, urezki@gmail.com, ast@fb.com, Eric Dumazet , Mina Almasry , Andrew Morton Subject: Re: [PATCH] hugetlb: select PREEMPT_COUNT if HUGETLB_PAGE for in_atomic use Message-ID: References: <20210311021321.127500-1-mike.kravetz@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 1a49dy863yg64g3t1p4p5nry3f47p7ct X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 325666000106 Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf25; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615455896-464989 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 Thu 11-03-21 10:32:24, Peter Zijlstra wrote: > On Thu, Mar 11, 2021 at 10:01:22AM +0100, Michal Hocko wrote: > > On Thu 11-03-21 09:46:30, Peter Zijlstra wrote: > > > On Wed, Mar 10, 2021 at 06:13:21PM -0800, Mike Kravetz wrote: > > > > from irq context. Changing the check in the code from !in_task to > > > > in_atomic would handle the situations when called with irqs disabled. > > > > > > It does not. local_irq_disable() does not change preempt_count(). > > > > You are right. Earlier I was suggesting to check of irq_disabled() as > > well http://lkml.kernel.org/r/YD4I+VPr3UNt063H@dhcp22.suse.cz > > > > back then it was not really clear to me that in fact we do care about > > spin locks more than irq disabled code. I am not even sure whether we > > need to care about irq disabled regions without any locks held that > > wouldn't be covered by in_atomic. But it would be safer to add > > irq_disabled check as well. > > Safer still is always doing it, replace it with if (true). > > What's the purpose, doing the minimal 'correct', of the maximal safe > solution? If we always defer to a WQ context then an admin wouldn't have any feedback from the syscall when releasing the pool. > The whole changelog reads like a trainwreck, but akpm already commented > on that. I picked out a small factual incorrectness, simply because if > you can't get that right, the whole argument looses weight. Is there any reason why in_atomic || irq_disabled wouldn't work universally? > That said, I don't think you actually need it, if as you write the lock > should be IRQ-safe, then you're worried about the IRQ recursion > deadlock: making hugetlb_lock irqsafe is a long way as explained by Mike elsewhere. Not only that. The upcoming hugeltb feature to have sparse vmemmap for hugetlb pages will need to allocate vmemmap when hugetlb page is to be freed back to the allocator. That cannot happen in any atomic context so there will be a need to tell those contexts for special casing. -- Michal Hocko SUSE Labs