Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2458654pxb; Fri, 29 Oct 2021 01:39:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyEDEHIm+OIHvY+OY9iHMS4qtWf0Xr62kKInVaRLZD/Mq1zASzuc6teO46+asppr0Juehfd X-Received: by 2002:a63:788e:: with SMTP id t136mr7243647pgc.432.1635496767062; Fri, 29 Oct 2021 01:39:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635496767; cv=none; d=google.com; s=arc-20160816; b=GmCsXA5+lAwhBQSYUa/FBDThNr6n/oB0/qxn+TH+gWCquFTMyWvSB5LTKMdtIbDuOB ln8RBaUyCx/ByO9QAFMqrOExnJAclg7+aRU90k8FCrCfEUBo0uiD6dRZ2LSbkkdo4Q2v Xgq7kY3quXYSfZM8W0U585nhzFAM5zi1YA/JDbCRS/HCHbgY5cVwJeRWNYGUrrwSz9gT U+Q20v6munm+kfWRairleDeIXP1tBVuCwwOT7AkJgupuW3CkYbDow+vm1N0hAqIQJvmv /aXSU7gDboZwfpFh5P85LOHRf0a3lf+Sn2hLAn748rupuoVGqviR8JK/JM8tUbtpKlRL ZR1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature:dkim-signature; bh=qZJtw3MieBAJxz2bywPNILccd9LrIRNQXFA0JlaFMeY=; b=fhG1iTWDlKrrLXCLiD6anqboTcQ4hP9WCsBt8MJexwQqcdTJEr5W74Zf7kgwAdZJ3A eaTpDFM4kQVu2ZSadNq1t0PKP9iTzkEM9SLf898GDqj+6v8nOF7MUjG2TsBx5SQ+XwP0 Jw78E2BpRFN7mCNjeEIYPiddkjInJP0ujXU2TNfKgphg0gyPRaxwxC6drj17aUZGVFFx /ePAFqTlSNQYmIkAeGcZLXOqJ5vbShHli96o3yqCJA/7r9Y+Ix79tHUZIrH+j0ldIzI8 1zUerhluzqyGPQ14QYN1Pr9zjP0fqWyfaR9FSQ7e9RXJ/sl8afeMBiLRFglcQWaL+eNx FWDg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=t6GZqZ2Z; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s7si6108177plr.331.2021.10.29.01.39.13; Fri, 29 Oct 2021 01:39:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=t6GZqZ2Z; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232498AbhJ2Ik1 (ORCPT + 99 others); Fri, 29 Oct 2021 04:40:27 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:44990 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232313AbhJ2Ik0 (ORCPT ); Fri, 29 Oct 2021 04:40:26 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 8DF1621979; Fri, 29 Oct 2021 08:37:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1635496677; 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=qZJtw3MieBAJxz2bywPNILccd9LrIRNQXFA0JlaFMeY=; b=t6GZqZ2ZrA/zWvBOmb2gYMX4wpzmCFE/5vROmmF10stABpPd4Vix4z1Av+pYE9LvhJqnJg XSGg1+c6+utFRvFbwllDCEwAkiejlzTQqeHcgSDCiefdpUUc91ZU6EbZCCgVxeEnvEfmLU +8yKiddofh2oiONcJ5SAK3Vch4rgK/E= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1635496677; 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=qZJtw3MieBAJxz2bywPNILccd9LrIRNQXFA0JlaFMeY=; b=6v5ygUCQdTegipKV02UYgWAHs+kPuWGntkmtDP/e3QhMktilEhvPCS/5fzjCEcqJGMyixs Y/gQKRaBvasxCQAA== Received: from suse.de (mgorman.udp.ovpn2.nue.suse.de [10.163.43.106]) (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 CED32A3B83; Fri, 29 Oct 2021 08:37:55 +0000 (UTC) Date: Fri, 29 Oct 2021 09:37:51 +0100 From: Mel Gorman To: Gang Li Cc: Jonathan Corbet , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Daniel Bristot de Oliveira , linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: Re: [PATCH v1] sched/numa: add per-process numa_balancing Message-ID: <20211029083751.GR3891@suse.de> References: <20211027132633.86653-1-ligang.bdlg@bytedance.com> <20211028153028.GP3891@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 29, 2021 at 02:12:28PM +0800, Gang Li wrote: > On 10/28/21 11:30 PM, Mel Gorman wrote: > > > > That aside though, the configuration space could be better. It's possible > > to selectively disable NUMA balance but not selectively enable because > > prctl is disabled if global NUMA balancing is disabled. That could be > > somewhat achieved by having a default value for mm->numa_balancing based on > > whether the global numa balancing is disabled via command line or sysctl > > and enabling the static branch if prctl is used with an informational > > message. This is not the only potential solution but as it stands, > > there are odd semantic corner cases. For example, explicit enabling > > of NUMA balancing by prctl gets silently revoked if numa balancing is > > disabled via sysctl and prctl(PR_NUMA_BALANCING, PR_SET_NUMA_BALANCING, > > 1) means nothing. > > > static void task_tick_fair(struct rq *rq, struct task_struct *curr, int > queued) > { > ... > if (static_branch_unlikely(&sched_numa_balancing)) > task_tick_numa(rq, curr); > ... > } > > static void task_tick_numa(struct rq *rq, struct task_struct *curr) > { > ... > if (!READ_ONCE(curr->mm->numa_balancing)) > return; > ... > } > > When global numa_balancing is disabled, mm->numa_balancing is useless. I'm aware that this is the behaviour of the patch as-is. > So I > think prctl(PR_NUMA_BALANCING, PR_SET_NUMA_BALANCING,0/1) should return > error instead of modify mm->numa_balancing. > > Is it reasonable that prctl(PR_NUMA_BALANCING,PR_SET_NUMA_BALANCING,0/1) > can still change the value of mm->numa_balancing when global numa_balancing > is disabled? > My point is that as it stands, prctl(PR_NUMA_BALANCING,PR_SET_NUMA_BALANCING,1) either does nothing or fails. If per-process numa balancing is to be introduced, it should have meaning with the global tuning affecting default behaviour and the prctl affecting specific behaviour. -- Mel Gorman SUSE Labs