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: <20230630144038.v2rv7qtrxi4ujhdg@airbuntu>
Date:   Fri, 30 Jun 2023 15:40:38 +0100
From:   Qais Yousef <qyousef@...alina.io>
To:     Xuewen Yan <xuewen.yan94@...il.com>
Cc:     Vincent Guittot <vincent.guittot@...aro.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Xuewen Yan <xuewen.yan@...soc.com>, mingo@...hat.com,
        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, ke.wang@...soc.com,
        zhaoyang.huang@...soc.com
Subject: Re: [RFC PATCH] sched/fair: update the vruntime to be max vruntime
 when yield

Hi Xuewen

On 03/01/23 16:20, Xuewen Yan wrote:
> On Wed, Mar 1, 2023 at 4:09 PM Vincent Guittot
> <vincent.guittot@...aro.org> wrote:
> >
> > On Wed, 1 Mar 2023 at 08:30, Xuewen Yan <xuewen.yan94@...il.com> wrote:
> > >
> > > Hi Vincent
> > >
> > > I noticed the following patch:
> > > https://lore.kernel.org/lkml/20230209193107.1432770-1-rkagan@amazon.de/
> > > And I notice the V2 had merged to mainline:
> > > https://lore.kernel.org/all/20230130122216.3555094-1-rkagan@amazon.de/T/#u
> > >
> > > The patch fixed the inversing of the vruntime comparison, and I see
> > > that in my case, there also are some vruntime is inverted.
> > > Do you think which patch will work for our scenario? I would be very
> > > grateful if you could give us some advice.
> > > I would try this patch in our tree.
> >
> > By default use the one that is merged; The difference is mainly a
> > matter of time range. Also be aware that the case of newly migrated
> > task is not fully covered by both patches.
> 
> Okay, Thank you very much!
> 
> >
> > This patch fixes a problem with long sleeping entity in the presence
> > of low weight and always running entities. This doesn't seem to be
> > aligned with the description of your use case
> 
> Thanks for the clarification! We would try it first to see whether it
> could resolve our problem.

Did you get a chance to see if that patch help? It'd be good to backport it to
LTS if it does.


Thanks

--
Qais Yousef

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ