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 DBDD4C433EF for ; Wed, 8 Sep 2021 07:06:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6D35360ED8 for ; Wed, 8 Sep 2021 07:06:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6D35360ED8 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 03EE5900002; Wed, 8 Sep 2021 03:06:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F30B96B0071; Wed, 8 Sep 2021 03:06:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF7EE900002; Wed, 8 Sep 2021 03:06:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) by kanga.kvack.org (Postfix) with ESMTP id CC9A96B006C for ; Wed, 8 Sep 2021 03:06:27 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 83D128249980 for ; Wed, 8 Sep 2021 07:06:27 +0000 (UTC) X-FDA: 78563522814.08.AC5C69C Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf01.hostedemail.com (Postfix) with ESMTP id 145BD504FBE1 for ; Wed, 8 Sep 2021 07:06:26 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 884162224B; Wed, 8 Sep 2021 07:06:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1631084785; 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=mw56HzEmlO2HCwIOHnTkhLtTlF65Hy4hZno8P/WeBwI=; b=mbI22tYI0wGZWVloc0Kx0Bxw+mkkGgFP4qO+bZO7FM3fbYSk+CO3JtOE2EFDI8He4kYR7C YJRds1fTOa2lxvXKMuKSfd8a15/FtxstdXCVM31RYKt/JF39Z0rqXTEcTJpB33THUpr+CA fzFolNXMadGyFINPdju+s41YjRVewXQ= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 50883A3B96; Wed, 8 Sep 2021 07:06:25 +0000 (UTC) Date: Wed, 8 Sep 2021 09:06:24 +0200 From: Michal Hocko To: Feng Tang Cc: Andrew Morton , David Rientjes , Mel Gorman , Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/page_alloc: detect allocation forbidden by cpuset and bail out early Message-ID: References: <1631003150-96935-1-git-send-email-feng.tang@intel.com> <20210908015014.GA28091@shbuild999.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210908015014.GA28091@shbuild999.sh.intel.com> Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=mbI22tYI; spf=pass (imf01.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Stat-Signature: zfgq33not6ow4h5jbswnyuuatg3wypyq X-Rspamd-Queue-Id: 145BD504FBE1 X-Rspamd-Server: rspam04 X-HE-Tag: 1631084786-473816 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 Wed 08-09-21 09:50:14, Feng Tang wrote: > On Tue, Sep 07, 2021 at 10:44:32AM +0200, Michal Hocko wrote: [...] > > While this is a good fix from the functionality POV I believe you can go > > a step further. Please add a detection to the cpuset code and complain > > to the kernel log if somebody tries to configure movable only cpuset. > > Once you have that in place you can easily create a static branch for > > cpuset_insane_setup() and have zero overhead for all reasonable > > configuration. There shouldn't be any reason to pay a single cpu cycle > > to check for something that almost nobody does. > > > > What do you think? > > I thought about the implementation, IIUC, the static_branch_enable() is > easy, it could be done when cpuset.mems is set with movable only nodes, > but disable() is much complexer, Do we care about disable at all? The point is to not have 99,999999% users pay overhead of the check which is irrelevant to them. Once somebody wants to use this "creative" setup then paying an extra check sounds perfectly sensible to me. If somebody cares enough then the disable logic could be implemented. But for now I believe we should be OK with only enable case. > as we may need a global reference > counter to track the set/unset, and the unset could be the time when > freeing the cpuset data structure, also one cpuset.mems could be changed > runtime, and system could have multiple cpuset dirs (user space usage > could be creative or crazy :)). > > While checking cpuset code, I thought more about configuring cpuset with > movable only nodes, that we may still have normal usage: mallocing a big > trunk of memory and do some scientific calculation, or AI training. It > works with current code. It might work but it would be inherently subtle because a single non-movable allocation will throw the whole thing off the cliff. I do not think we want to even pretend we support such a setup. -- Michal Hocko SUSE Labs