Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp1841514rwb; Sun, 4 Sep 2022 03:28:20 -0700 (PDT) X-Google-Smtp-Source: AA6agR4yV+latAuMGeWrwDYGw8KeXHeae0ljbo6ymfqQ8yKdME5Rj3vvGzHRNvRIMbt5AsCT3LFy X-Received: by 2002:a05:6a00:8cc:b0:52c:7ab5:2ce7 with SMTP id s12-20020a056a0008cc00b0052c7ab52ce7mr44166465pfu.28.1662287300640; Sun, 04 Sep 2022 03:28:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662287300; cv=none; d=google.com; s=arc-20160816; b=ue+h0uO0/Fi49ayV04T0qqcxXm9s9PR5atoLAqscBcxfkgLSNjrYjyq8Q5UXszOJjH qrHyWd+g5Mj3hSCBS+9qye9taRRIN5TcDly7AlV1YUzovfXj1/tOy97+oAH07MRooM4p 7SyUzMgHbSf/wywviZvPuHWZ8oLbIRmKPciHr3EzJeLxuJ+iKx16upZMJfek4gHvUDtC zEPowpX1Jag2y9Ivt9RLzYkP7xyw2WPkQz0+12MNKBhc1zrV7sXA+M3kiGDL2cT/9TMP 9wdaKX2TvuOrz6AThJKhB1HNz1eF1a8dMLiD/5v1dNqQKxl06OcD7ZbArXStXrAabk9F DGPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=O3iIl1Mah8kQtl3WghuXwmguMd4Xu3bPcYKCjyUtt4c=; b=kHMEO3ckbM2JdCeAroXqaMAwZoA+g9cRWLCwkXed6Dazqjl+lHSceejSSWd1gdXlyu WJPD0/BiGhFmw8mQxyondlTPJr+iHa1k5LN/s4BTKNGzmti4yJRNFdrbTfy5lQ8HUrcP 13GBQ/4Iv8+CQzVRQbsPQPEVWMFb27bsc+80zZnR2a7yVyIM6rJH6FZ07NjLMhpDEe64 SgDkuHcWLtr/vs6qlwvjEIib1x0/UM7bPbWlD8u5JNUJXRpl8fHT7G0SD1bycgh5bIAP M+oY40iJs0sG8621ixOwzxGODdH0mDVKlbH0QmQjEpY9ppZY6lYj6sK6JglEIgKythiC 0ANw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=aI3AGoqi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q21-20020a63e215000000b0042a93b62540si7703565pgh.68.2022.09.04.03.28.07; Sun, 04 Sep 2022 03:28:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=aI3AGoqi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233742AbiIDKJs (ORCPT + 99 others); Sun, 4 Sep 2022 06:09:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55926 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233711AbiIDKJo (ORCPT ); Sun, 4 Sep 2022 06:09:44 -0400 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4F5A513F4E; Sun, 4 Sep 2022 03:09:42 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id t14so472811wrx.8; Sun, 04 Sep 2022 03:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date; bh=O3iIl1Mah8kQtl3WghuXwmguMd4Xu3bPcYKCjyUtt4c=; b=aI3AGoqier4Ibi2qlq8ENNTmbh71D0vu39dKS16YHZERYD1YCsB//U3lRf+UsIGaNA 3Vm4UrXrVwIvapd8+a6iVGGTG+6Hvjpd0ko3PopQYkWl7vUj8mdWNdcq0Yn1GU4Oppqb +hrWT2wzdm40yE+Z/KQJ/5Nu+m5WDV8jDlI+UHfOnClb+gehATqWjqyNK9jlKNzjkgGN mz64BrddlL7G3HVggeVGfThJiJYgUXiVmUF9lqBlZ3Ah5TYfJZ3cQG3TNa1Ef0CsNE0Q /5kwQcXpsoJuSOqIwtxRCZltfh1VWbv/cUzSTQdOcKXpKVBSL7veS0aiwZ1uknac23M5 EWsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date; bh=O3iIl1Mah8kQtl3WghuXwmguMd4Xu3bPcYKCjyUtt4c=; b=UxeVQODwekLBdKfkBIZxzaeJ9LM38rE7ziPb85B8UQnnds6EduwAMqOwAtCI0EOLLV 4II/jxkX6Y+zg9LcKz0OOVUSvd1wPwjB531AmYXTRGmhWtXQb/ZqM9UEOjjYQfC8rMtc xGEnRVO48Zuez3NJrJEz/qFYTFHO4yepoxBkubxol1TYEA/6yGisv/lGduN1UGIg4KHQ hP1IeDTzNu/t4SJ9mwfgep5M6G9Me66sGPFMp1XZCAhcIGfzz/o8Iv2ZGDfRyoEnsb/5 oUR2C1bBK5hG74sDxRElqAb7kRnJlaezjOrbn1NDwnso9Lyoe9MIodPfWSIVZJ26Cd4W i2RQ== X-Gm-Message-State: ACgBeo3GFyV6JTC2xQZtI7OgBGoNG1JMo+0+3h7k80sk6FHmoO0fPYjr KbjqS9n/WzqMZvEJxX5SN5w= X-Received: by 2002:a05:6000:1a87:b0:222:2c85:2f5b with SMTP id f7-20020a0560001a8700b002222c852f5bmr22353236wry.654.1662286180290; Sun, 04 Sep 2022 03:09:40 -0700 (PDT) Received: from gmail.com (1F2EF751.nat.pool.telekom.hu. [31.46.247.81]) by smtp.gmail.com with ESMTPSA id k23-20020a05600c1c9700b003a531c7aa66sm7910968wms.1.2022.09.04.03.09.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Sep 2022 03:09:39 -0700 (PDT) Sender: Ingo Molnar Date: Sun, 4 Sep 2022 12:09:37 +0200 From: Ingo Molnar To: Peter Zijlstra Cc: rjw@rjwysocki.net, oleg@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, mgorman@suse.de, ebiederm@xmission.com, bigeasy@linutronix.de, Will Deacon , linux-kernel@vger.kernel.org, tj@kernel.org, linux-pm@vger.kernel.org Subject: Re: [PATCH v3 6/6] freezer,sched: Rewrite core freezer logic Message-ID: References: <20220822111816.760285417@infradead.org> <20220822114649.055452969@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220822114649.055452969@infradead.org> X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no 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 * Peter Zijlstra wrote: > --- a/include/linux/sched.h > +++ b/include/linux/sched.h > @@ -81,25 +81,32 @@ struct task_group; > */ > > /* Used in tsk->state: */ > -#define TASK_RUNNING 0x0000 > -#define TASK_INTERRUPTIBLE 0x0001 > -#define TASK_UNINTERRUPTIBLE 0x0002 > -#define __TASK_STOPPED 0x0004 > -#define __TASK_TRACED 0x0008 > +#define TASK_RUNNING 0x000000 > +#define TASK_INTERRUPTIBLE 0x000001 > +#define TASK_UNINTERRUPTIBLE 0x000002 > +#define __TASK_STOPPED 0x000004 > +#define __TASK_TRACED 0x000008 > /* Used in tsk->exit_state: */ > -#define EXIT_DEAD 0x0010 > -#define EXIT_ZOMBIE 0x0020 > +#define EXIT_DEAD 0x000010 > +#define EXIT_ZOMBIE 0x000020 > #define EXIT_TRACE (EXIT_ZOMBIE | EXIT_DEAD) > /* Used in tsk->state again: */ > -#define TASK_PARKED 0x0040 > -#define TASK_DEAD 0x0080 > -#define TASK_WAKEKILL 0x0100 > -#define TASK_WAKING 0x0200 > -#define TASK_NOLOAD 0x0400 > -#define TASK_NEW 0x0800 > -/* RT specific auxilliary flag to mark RT lock waiters */ > -#define TASK_RTLOCK_WAIT 0x1000 > -#define TASK_STATE_MAX 0x2000 > +#define TASK_PARKED 0x000040 > +#define TASK_DEAD 0x000080 > +#define TASK_WAKEKILL 0x000100 > +#define TASK_WAKING 0x000200 > +#define TASK_NOLOAD 0x000400 > +#define TASK_NEW 0x000800 > +#define TASK_FREEZABLE 0x001000 > +#define __TASK_FREEZABLE_UNSAFE (0x002000 * IS_ENABLED(CONFIG_LOCKDEP)) > +#define TASK_FROZEN 0x004000 > +#define TASK_RTLOCK_WAIT 0x008000 > +#define TASK_STATE_MAX 0x010000 Patch ordering suggestion: would be really nice to first do the width adjustment as a preparatory patch, then the real changes. The mixing obscures what the patch is doing here, that we leave all bits before TASK_NEW unchanged, add in TASK_FREEZABLE, __TASK_FREEZABLE_UNSAFE & TASK_FROZEN to before TASK_RTLOCK_WAIT. Btw., wouldn't it be better to just add the new bits right before TASK_STATE_MAX, and leave the existing ones unchanged? I don't think the order of TASK_RTLOCK_WAIT is relevant, right? > /* Convenience macros for the sake of set_current_state: */ > #define TASK_KILLABLE (TASK_WAKEKILL | TASK_UNINTERRUPTIBLE) > @@ -1714,7 +1721,6 @@ extern struct pid *cad_pid; > #define PF_NPROC_EXCEEDED 0x00001000 /* set_user() noticed that RLIMIT_NPROC was exceeded */ > #define PF_USED_MATH 0x00002000 /* If unset the fpu must be initialized before use */ > #define PF_NOFREEZE 0x00008000 /* This thread should not be frozen */ > -#define PF_FROZEN 0x00010000 /* Frozen for system suspend */ > #define PF_KSWAPD 0x00020000 /* I am kswapd */ > #define PF_MEMALLOC_NOFS 0x00040000 /* All allocation requests will inherit GFP_NOFS */ > #define PF_MEMALLOC_NOIO 0x00080000 /* All allocation requests will inherit GFP_NOIO */ yay. BTW., we should probably mark/document all PF_ holes with a PF__RESERVED kind of scheme? Something simple, like: #define PF_NPROC_EXCEEDED 0x00001000 /* set_user() noticed that RLIMIT_NPROC was exceeded */ #define PF_USED_MATH 0x00002000 /* If unset the fpu must be initialized before use */ + #define PF__RESERVED_04000 0x00004000 /* Unused */ #define PF_NOFREEZE 0x00008000 /* This thread should not be frozen */ + #define PF__RESERVED_10000 0x00010000 /* Unused */ #define PF_KSWAPD 0x00020000 /* I am kswapd */ #define PF_MEMALLOC_NOFS 0x00040000 /* All allocation requests will inherit GFP_NOFS */ #define PF_MEMALLOC_NOIO 0x00080000 /* All allocation requests will inherit GFP_NOIO */ ? Thanks, Ingo