linux-kernel - Re: [PATCH v5 4/7] sched/fair: Take into account latency priority at wakeup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y1QHcZSmKAX2SWgu@chenyu5-mobl1>
Date:   Sat, 22 Oct 2022 23:08:33 +0800
From:   Chen Yu <yu.c.chen@...el.com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
CC:     <mingo@...hat.com>, <peterz@...radead.org>,
        <juri.lelli@...hat.com>, <dietmar.eggemann@....com>,
        <rostedt@...dmis.org>, <bsegall@...gle.com>, <mgorman@...e.de>,
        <bristot@...hat.com>, <vschneid@...hat.com>,
        <linux-kernel@...r.kernel.org>, <parth@...ux.ibm.com>,
        <qais.yousef@....com>, <chris.hyser@...cle.com>,
        <valentin.schneider@....com>, <patrick.bellasi@...bug.net>,
        <David.Laight@...lab.com>, <pjt@...gle.com>, <pavel@....cz>,
        <tj@...nel.org>, <qperret@...gle.com>,
        <tim.c.chen@...ux.intel.com>, <joshdon@...gle.com>, <timj@....org>
Subject: Re: [PATCH v5 4/7] sched/fair: Take into account latency priority at
 wakeup

Hi Vincent,
On 2022-09-25 at 16:39:05 +0200, Vincent Guittot wrote:
[...]
> +static long wakeup_latency_gran(struct sched_entity *curr, struct sched_entity *se)
> +{
> +	long latency_offset = se->latency_offset;
> +
> +	/*
> +	 * A negative latency offset means that the sched_entity has latency
> +	 * requirement that needs to be evaluated versus other entity.
> +	 * Otherwise, use the latency weight to evaluate how much scheduling
> +	 * delay is acceptable by se.
> +	 */
> +	if ((se->latency_offset < 0) || (curr->latency_offset < 0))
Maybe use latency_offset < 0 directly?
BTW, is it the policy that requires the user to provide a negative
latency nice so as to tell the kernel to compare between two tasks?
Maybe I missed the scenario, I'm thinking of the reason why we used
" || " rather than " && " above. To be more specific, why not comparing
se and curr only when they both have high requirement on latency(negative)?

The benefit of using "||" I'm thinking of is that, if se->latency_offset < 0
and curr->latency_offset > 0, the latency_offset would be even smaller than
se->latency_offset, which will make the preemption easier. And vice verse.

thanks,
Chenyu
> +		latency_offset -= curr->latency_offset;
> +
> +	return latency_offset;
> +}