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: <d0edcb38-709f-2c29-b541-cc39d41d378c@linux.vnet.ibm.com>
Date:   Sun, 13 Nov 2022 13:32:04 +0530
From:   shrikanth suresh hegde <sshegde@...ux.vnet.ibm.com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH v7 5/9] sched/fair: Take into account latency priority at
 wakeup


>   /*
>    * Preempt the current task with a newly woken task if needed:
>    */
> @@ -4566,7 +4568,7 @@ check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr)
>   {
>   	unsigned long ideal_runtime, delta_exec;
>   	struct sched_entity *se;
> -	s64 delta;
> +	s64 delta, offset;
>   
>   	ideal_runtime = sched_slice(cfs_rq, curr);
>   	delta_exec = curr->sum_exec_runtime - curr->prev_sum_exec_runtime;
> @@ -4591,10 +4593,12 @@ check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr)
>   	se = __pick_first_entity(cfs_rq);
>   	delta = curr->vruntime - se->vruntime;
>   
> -	if (delta < 0)
> +	offset = wakeup_latency_gran(curr, se);
> +	if (delta < offset)
>   		return;
>   
> -	if (delta > ideal_runtime)
> +	if ((delta > ideal_runtime) ||
> +	    (delta > get_latency_max()))
>   		resched_curr(rq_of(cfs_rq));
>   }
>   
>
Hi Vincent,

I am not sure if i have understood this below change correctly.

wakeup_latency_gran - this function returns difference in latency nice offsets.
Hence the more negative the value, it means se has more latency requirement
compared to current. Hence se should preempt the current here right?
  
we are comparing delta to get_latency_max and ideal_runtime, both of which can
be higher positive value, hence we will not preempt. that is not what we want
right?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ