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;
Date:   Sat, 5 Nov 2022 22:32:43 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     Vincent Guittot <vincent.guittot@linaro.org>
CC:     <mingo@redhat.com>, <peterz@infradead.org>,
        <juri.lelli@redhat.com>, <dietmar.eggemann@arm.com>,
        <rostedt@goodmis.org>, <bsegall@google.com>, <mgorman@suse.de>,
        <bristot@redhat.com>, <vschneid@redhat.com>,
        <linux-kernel@vger.kernel.org>, <parth@linux.ibm.com>,
        <qais.yousef@arm.com>, <chris.hyser@oracle.com>,
        <patrick.bellasi@matbug.net>, <David.Laight@aculab.com>,
        <pjt@google.com>, <pavel@ucw.cz>, <tj@kernel.org>,
        <qperret@google.com>, <tim.c.chen@linux.intel.com>,
        <joshdon@google.com>, <timj@gnu.org>, <kprateek.nayak@amd.com>,
        <youssefesmat@chromium.org>, <joel@joelfernandes.org>
Subject: Re: [PATCH v7 1/9] sched/fair: fix unfairness at wakeup
Message-ID: <Y2Z0C2whs6pnPLvi@chenyu5-mobl1>
References: <20221028093403.6673-1-vincent.guittot@linaro.org>
 <20221028093403.6673-2-vincent.guittot@linaro.org>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20221028093403.6673-2-vincent.guittot@linaro.org>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?oPxdtg6n3a8WMeL+xAaFXJ+6e2H69tzkbHaNl0Sp7QtTjSpbC6F+ftis8to5?=
 =?us-ascii?Q?qGTWrlLplC4FZRuP+EgI62yoHzt64Da9PXYnrQJlUdEvlr9Bh2Ezf3rHsd4o?=
 =?us-ascii?Q?6SkL5Ac63v60jbcChnm7S1YcBCmk12YY2nrEDdsUUcGcw+MvVU8B96lE29mq?=
 =?us-ascii?Q?zNoCeHBOcbVVco/5OJVoiuLzAYRbksWwsQWk7SGhw0MvMMiYWbRkLWe8Ag7W?=
 =?us-ascii?Q?WGggjmqmW0cDJlwMEj8zBt5OZm/cP1Yg5ORAmQObmcx9B8u8QCnsKyGIrrD5?=
 =?us-ascii?Q?FFPcsEGvIzpnO8d7Yp+MpHJiK5Ja1jM/du0/4xIfSKKU8EJSvdIyp8X5Zg/z?=
 =?us-ascii?Q?AvOb43w1XShhugTa9q+ChB25YxIYUIKWVTNIT5wzoGlYE5zsaH0tAwUn8Ijm?=
 =?us-ascii?Q?wIj00KYXYCP4YYTq8gcuF4Xak/9RAT6EfLdFTFOIbG+Dv8D/w9xhZ7WKC1Yw?=
 =?us-ascii?Q?ApqNf4Wcvd7WfN8QjgVBz0+N+GS41ZS6Y5wCFikifkTFGXJdXZTme6FvRRl1?=
 =?us-ascii?Q?6ZyXgTtLkUHvHeBqWs5aq1IihPl2Jur6qDZ7K+eLyqdM/O6YoJN0uuLMEgQh?=
 =?us-ascii?Q?U1nJ7dogW+PySypjJcNxNmq/OuPUgiqk2UvAA0CP2EvjNgQ8mA6ysAKwMG/2?=
 =?us-ascii?Q?dABvBrDTsl67bm0j8H+2Av6O+1s98Un2D7a0jNeUyfqvHkXEvH8ziTyVJdkT?=
 =?us-ascii?Q?qvV1Q2IDZKOcgi5GK9YoNzbopqIPedDNhvFe88kCJfaueqf1MAp0s92ekx0w?=
 =?us-ascii?Q?+arlvJohvVXSCHT7SYqmMozFOUzGJA3xB6UuHTe5Xh+3mryzDm/QA3Tf1FwG?=
 =?us-ascii?Q?2skfbLC0sjjxd5bYKdLpG/e13eyVRVfFSrJ6viI2albtKV6ngCH8GPNgu3au?=
 =?us-ascii?Q?q0RTT2Ok+tuL7GBOg2qMhQmWCnZdns+TTShBMUaVvlp88cz6iO2Dg3Ve6gd3?=
 =?us-ascii?Q?vvUSqpds5ftnm8pVU9/XQIXf15qV/1Ga1gT9AwfyGoS5NpLyKBVxiw7zuPAr?=
 =?us-ascii?Q?FiM8wHXIdOjWq9ZS/kLCikLvbJTwxkiY0CtgR1WgTCaFspo9oiudlRX/QoUw?=
 =?us-ascii?Q?2KSKXk9HZT9tUVQ+A22G3dMdYP3Q94YHL8O+h25J92PX3uhsRZH7zJn1n8+r?=
 =?us-ascii?Q?N4e5i5lbh29ukHjnSVtHBTs+7xh0Nk1ut3feg/eDarSApv8Em8XX7dYmtXfQ?=
 =?us-ascii?Q?uYawmqf6N6eykoJY2lOH0sftrR+KQtA/2m4Lc2JAAMj9gZZws1L1dG96qbXT?=
 =?us-ascii?Q?cxBjzOJLMeV0NI9lL2DeGHN8LXyTwAKN1DQgO9t5gFFsgp7BN8RDv4Bkqqlr?=
 =?us-ascii?Q?36/l5HnzSp5RUkXqO8u39p7KeaNK1jELibnL/i0BCBd9m2GNIVbskNCYL1IS?=
 =?us-ascii?Q?cOpyF0drca0iOhC8FFaqSCkIPf+Rx5RKP5suFUFsg9Z0l77fUSDOJBKLVDVh?=
 =?us-ascii?Q?QO5lffqBO6vOjvnMZHavzcaOKliN9q2FDk33IzXgq5mMZxyqGr6XaXsLNIZi?=
 =?us-ascii?Q?T/m0D9vdlZdzVFi38Rp6+2dSLOzWPfgdaX4oARTK2kw4lxi8Ri0WvJ+6BNyq?=
 =?us-ascii?Q?HwaZE7cc0kZmTCvoUDGU3Z2Qt2L3ZNH+h+DF5kxw?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 429cea9e-8264-4f21-d151-08dabf3aa78b
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Nov 2022 14:33:06.7719
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 976/Xdcj7ogOswiOa0dJQexzO46Sw9LmP7Y9TogGZ90dRDgcUEU1a353NRPEicF3AFUvwPUnASE4GidkOwTzRA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4759
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_PASS,SPF_NONE autolearn=ham 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2022-10-28 at 11:33:55 +0200, Vincent Guittot wrote:
[snip] 
> +static inline unsigned long  get_latency_max(void)
> +{
> +	unsigned long thresh = get_sched_latency(false);
> +
> +	thresh -= sysctl_sched_min_granularity;
> +
May I know why we substract sysctl_sched_min_granularity above?
I thought thresh -= 1 would be enough to let the waking task preempt
the current one, because:
When a long sleeping task is enqueued on this rq, its vruntime is set
to cfs_rq->min_vtime - latency, so
diff = curr->vtime - cfs_rq->min_vtime + latency,
since (curr->vtime - cfs_rq->min_vtime) >= 0, if we set the thresh to
(latency - 1), the diff is guaranteed to be bigger than thresh and
the waking task can preempt current task.

thanks,
Chenyu
> +	return thresh;
> +}