Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2427318pxb; Fri, 29 Oct 2021 00:50:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwUUu+kn6gwetPEyQUrrbVJmTbQIrHLkPhkf0fRrgs5uRPLB5CdJFac5lzZohXizp5AF/6m X-Received: by 2002:a17:90a:1101:: with SMTP id d1mr18405292pja.205.1635493849604; Fri, 29 Oct 2021 00:50:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635493849; cv=none; d=google.com; s=arc-20160816; b=vTiJEuu9TWLTIwpPVhPWhL9UGu9UXHeop+6SXnJxdLLeip1ls6ZCx5jYZIHbhZKs2Y H1jReIKl6cRcfw8LAedgT/zoR19xHVfA7EH+AdSAg7pTZQPJrbWN5tu4ashWeUoz7Ztt 1Z9VPNychv8aR2AEsT51Rr3lQ9xoBV1JE/pDIjlaeA+NQ+jEHrw6aTetgNw0+aH462NK hE8ECulONlnHC5wPl+lKDkL6fIFiSHuAb3p+3GISa7vyn8knGvFg5/V5SP4a+gure+6c rY2UCZKL7C/hr/i5I5Xi5p+l0HLkjE6KkX6D179cK/upDO6/Gr4w2Y8odsr//kZZmgkd A/XA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=vjqTlAq/8atUNGknBengC56rv9Dz2YcbvxQpL6f31NE=; b=F1WS+rLauel/h68na4OmkcnDxPoIaNG0SvJ0VaJyJ2Rh58rrwVq3Br7DdBvl4yjeDq hHjLuLSxWViejV4Gb3nfj47moyfEcpkg43G2bVWXA/RqvVShkRwYyFfQ6mMh+ufWY9bz yEDbHQPJuHs4H0UgNqKby7M580ROmXQhRtOigCB9G1+vp0nxBxHjfH/g/ZLM1JJcKiK9 wdvh072ZIeySOuC/CbeQDM7EoBdU7OVow4oqYLSYMiH/5/Cv25BqXLQUZnPxHOyxwcbI ib6M5OFNquTnoszgZEj8MVKJlTfG7rXypS9DUMbQloS3fo8fcjYFLeK+cyNiB8sUkL/d +UUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=4NWQ97D8; 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=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i13si6258129pgs.519.2021.10.29.00.50.36; Fri, 29 Oct 2021 00:50:49 -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=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=4NWQ97D8; 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=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232397AbhJ2HwC (ORCPT + 99 others); Fri, 29 Oct 2021 03:52:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232307AbhJ2Hvb (ORCPT ); Fri, 29 Oct 2021 03:51:31 -0400 Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FD06C061766 for ; Fri, 29 Oct 2021 00:49:03 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id r12so35829675edt.6 for ; Fri, 29 Oct 2021 00:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vjqTlAq/8atUNGknBengC56rv9Dz2YcbvxQpL6f31NE=; b=4NWQ97D8av1bcOmAuQzWks2cBvv6sEDFs9N8sqanD4uhWTidcfYo3hBwx+DyCNFz1K P4C+s2YWl0gtXhIEz4s/whnD2DqPHxtpemt8r9bU+0/beruJ6D0okHZ8gattocaYAXEv Zybb+4y2JNS6+rpvFo4Ectd4zS13QmraLGofH2mPNjDu9wd4ORTSd/6hT5VwdRxXkLxn F1ewJRoO/QNgJhKynXm88FBtssDG+yUlM9zauo+3ocX/ytwveSWrB/tl11tDpcdmyEHQ cxqna2wQ4HpL7O/dzDhj25Kv2djOE8/xDRnIPI1r/h0QlWADoXnouRt9Tdu3nKvKCxTs dQkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vjqTlAq/8atUNGknBengC56rv9Dz2YcbvxQpL6f31NE=; b=KbYc35wY/9Q59YQNLk0RbnV/97DqGqajJPTrqWSHyZBGEcuzfAjp6BfrDiFk1Xri6M BIlwuGkRSTG1OcjJ+oBRl0KRZd4WhUJh7masZXLmc2XwBHtMBgMwcomj8ww3zSBGwnQx ZypKuOw2ZGqYPNONQ+MXlDHA+wOjYqG3CgqJQavfP/Avt8W2W6HEIEk5SYphpjvvNjXF 5e0080nnBmuND3SmONnsrUKMHkqu4W9u/B5ol0ZFPdvLqWWgBQbi176vf2TRBtxuQIw6 zD8P91co6i4mzf7FXZ7cz07yWTYlq/pOFnZ0Zoc0azexOhKZV971/+W6ANdA1R7amq06 mX/A== X-Gm-Message-State: AOAM530psufMhxKIxpH9dK3Dr443kX2vK+5+LBih0AlorWPbJaf0dfs5 ejEfqjn1zCDqln0lKTQYCTi+Z1MnLkEDy2Cl/s7xfA== X-Received: by 2002:a17:906:c18c:: with SMTP id g12mr11994765ejz.458.1635493741880; Fri, 29 Oct 2021 00:49:01 -0700 (PDT) MIME-Version: 1.0 References: <20211027132633.86653-1-ligang.bdlg@bytedance.com> <20211028153028.GP3891@suse.de> In-Reply-To: <20211028153028.GP3891@suse.de> From: =?UTF-8?B?5p2O5riv?= Date: Fri, 29 Oct 2021 15:48:50 +0800 Message-ID: Subject: Re: [External] Re: [PATCH v1] sched/numa: add per-process numa_balancing To: Mel Gorman 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 28, 2021 at 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. So I think prctl(PR_NUMA_BALANCING, PR_SET_NUMA_BALANCING,0/1) should return an error instead of modifying 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?