Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1685525pxb; Wed, 9 Feb 2022 02:09:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJzF33bBtmYr0An+6YFcgG3+tzDyMCZYftXFGQMa9+dNN09CnLhcacB+Ir/n+CzpIdbkfkgm X-Received: by 2002:a17:902:680f:: with SMTP id h15mr1410790plk.17.1644401370626; Wed, 09 Feb 2022 02:09:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644401370; cv=none; d=google.com; s=arc-20160816; b=UExjucXUyncSPyMSzrM4u5WV/y9yT4rWLlp8YYC/OSO1VpNPMv2PCJG8gUjNmgQK2h n5ry8NeBHCC5d5nHNgVjX3r3Lssilme97xAlzzs8V8zY0CsGxHsOrwJbEEQIKrNyLbEN 8Txvu6HQboNXlxUdyQwp/RG93oMZbrCNFBA2MQVyU4uyHSvcRaxQxkS+uZKNlfii66e+ 9H6p0fWALAto6t5aSYT0tALJrPHZ4STKGOYsYteymcElXKzmO5lAxZDcOs78fryFqw/Z IwxrEPJ561iwFbjqK+UhO7vm1h5mFp47wPd7o8LGCo/HC9iGJ4MfcdyV2Apix8XsEUEu afmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=a/iY+LYCIITobxV+U+gryLnkcw30JcLX+QDe3StT71U=; b=XhBdOJa25yJ3I1iLOKuNSc7fWeBcK9TEmPZ0LrbigIGC7KNCv9Jg3EEuUayeFhol08 UYPBEdQqPb+b8xk0TWIx44o2VJecuKp+U13hvSsLiIb3DAc8fde+3WF1FHn6VpgQnauE 4jxBBFNwsLV1D2iJyO89Lgod2jZImKBBqB7CpIH/kgLqYKt6b/Igjrybph+SF4UBM0lH 2sB5nEO3g72nc7B4Q7fUCqE5vJWyP1Y+9jOD0ra3z1qK+6klWVBdtYXiwoAhpEA4hR41 Y2hrwLmSOcH0jH+CW0v/Cgus4pU5um8jQOgKBimBTV7o+QORSHyOVxOl9OJosWMBL02E Um2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=Cu6tSzvd; 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 j12si15721022pfu.247.2022.02.09.02.09.18; Wed, 09 Feb 2022 02:09:30 -0800 (PST) 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=Cu6tSzvd; 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 S230090AbiBHDq7 (ORCPT + 99 others); Mon, 7 Feb 2022 22:46:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60120 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245562AbiBHDq4 (ORCPT ); Mon, 7 Feb 2022 22:46:56 -0500 Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22412C0401E8 for ; Mon, 7 Feb 2022 19:46:55 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id w1so3205311plb.6 for ; Mon, 07 Feb 2022 19:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=a/iY+LYCIITobxV+U+gryLnkcw30JcLX+QDe3StT71U=; b=Cu6tSzvdr3yyYqAV76D+Y74xDnkWul7CsRpMnMutOz8e+8VYQMvVcJH+A170U72vZH zj/g2rjBg0t9e/dg5i8cF/3xQHRRdO5TXCJnaA5DJYoQEZwoxZFi8GE3zeecFrE4rJSz F3l+erY+2uVOyLur97/KP72wIS4yoL8Y4j7U7b3ipc3xw/iFtKSv926FtSOBRzWqs1BN Uk/jQBNcqc4gXe54CgSZn54/1Xok42N9zuY5LGJpakyLp2Y/10LcRGYhM8Mf9F4+Oy/K L8lYSIxzHGo8vu+ba/qqBS8wYPbq5YkFlrjJVQAvz22D3cKe1mm+nx+BNgXlbDiwBtQ0 BH9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=a/iY+LYCIITobxV+U+gryLnkcw30JcLX+QDe3StT71U=; b=PkPsxwxIbBpu0uVKOQZ18udNnlATt55umY1xsiOFgW3pDKlF4fY56Knjqz4m1rcwnd GLW87/Gh0IW30RaWvcmOX1F45JlbmFwKtyNB1GKv/2II12Aryr84+SEkgBfCihC8gMwL kAUYsFOLdFw3D7PZ/DYgCnkq9HMvb9pinJnC0tFYWSDJ1z5FMgHgdNImCKpIhMP6wUL3 rTkPMXFQ7WC0U/04f+hZJ4C1N73vGUrSQHeMQAb+0jwpIoUaIeaRfhhVNzEadtEAu6P6 gdX9V6f9pdDk3gxoK6VlaYIbzLmz61f3ZbLupGv3OzbCcAf6Itu26IqqYm+vVDrfi5/R sx+w== X-Gm-Message-State: AOAM530cD9YkW7wJCxkHkWN9ZI2mbri+ThBo7osgmXL2Kd9q0CUZ4sb4 pQ6A67I7obve3v5DTCdg9s2YLQ== X-Received: by 2002:a17:902:a9c2:: with SMTP id b2mr2696201plr.168.1644292014639; Mon, 07 Feb 2022 19:46:54 -0800 (PST) Received: from [10.76.43.192] ([61.120.150.76]) by smtp.gmail.com with ESMTPSA id d12sm9379702pgk.29.2022.02.07.19.46.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Feb 2022 19:46:54 -0800 (PST) Message-ID: <43428234-93e3-806a-b0ff-0f1c2d7b7cb9@bytedance.com> Date: Tue, 8 Feb 2022 11:46:45 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: Re: [PATCH v3] sched/numa: add per-process numa_balancing Content-Language: en-US To: Peter Zijlstra Cc: Jonathan Corbet , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, songmuchun@bytedance.com, zhengqi.arch@bytedance.com References: <20211206024530.11336-1-ligang.bdlg@bytedance.com> From: Gang Li In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/1/12 22:43, Peter Zijlstra wrote: > On Mon, Dec 06, 2021 at 10:45:28AM +0800, Gang Li wrote: >> This patch add a new api PR_NUMA_BALANCING in prctl. >> >> A large number of page faults will cause performance loss when numa >> balancing is performing. Thus those processes which care about worst-case >> performance need numa balancing disabled. Others, on the contrary, allow a >> temporary performance loss in exchange for higher average performance, so >> enable numa balancing is better for them. >> >> Numa balancing can only be controlled globally by >> /proc/sys/kernel/numa_balancing. Due to the above case, we want to >> disable/enable numa_balancing per-process instead. >> >> Add numa_balancing under mm_struct. Then use it in task_tick_fair. >> >> Set per-process numa balancing: >> prctl(PR_NUMA_BALANCING, PR_SET_NUMAB_DISABLE); //disable >> prctl(PR_NUMA_BALANCING, PR_SET_NUMAB_ENABLE); //enable >> prctl(PR_NUMA_BALANCING, PR_SET_NUMAB_DEFAULT); //follow global > > This seems to imply you can prctl(ENABLE) even if the global is > disabled, IOW sched_numa_balancing is off. > Of course, this semantic has been discussed here FYI. https://lore.kernel.org/all/20211118085819.GD3301@suse.de/ On 11/18/21 4:58 PM, Mel Gorman wrote: > On Thu, Nov 18, 2021 at 11:26:30AM +0800, Gang Li wrote: >> 3. prctl(PR_NUMA_BALANCING, PR_SET_NUMAB_ENABLE); //enable > > If PR_SET_NUMAB_ENABLE enables numa balancing for a task when > kernel.numa_balancing == 0 instead of returning an error then sure. >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index 884f29d07963..2980f33ac61f 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -11169,8 +11169,12 @@ static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued) >> entity_tick(cfs_rq, se, queued); >> } >> >> - if (static_branch_unlikely(&sched_numa_balancing)) >> +#ifdef CONFIG_NUMA_BALANCING >> + if (curr->mm && (curr->mm->numab_enabled == NUMAB_ENABLED >> + || (static_branch_unlikely(&sched_numa_balancing) >> + && curr->mm->numab_enabled == NUMAB_DEFAULT))) >> task_tick_numa(rq, curr); >> +#endif >> >> update_misfit_status(curr, rq); >> update_overutilized_status(task_rq(curr)); > > There's just about everything wrong there... not least of all the > horrific coding style. horrible code, yes. I'll do some code clean. -- Thanks Gang Li