linux-kernel - Re: [PATCH 00/24] Complete EEVDF

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: <CAKfTPtA671h00MdA+CYW5tckxfk+9SVoH6RowR1Ut3_LJY1rjQ@mail.gmail.com>
Date: Wed, 14 Aug 2024 19:25:11 +0200
From: Vincent Guittot <vincent.guittot@...aro.org>
To: Mike Galbraith <efault@....de>
Cc: Peter Zijlstra <peterz@...radead.org>, mingo@...hat.com, juri.lelli@...hat.com, 
	dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com, 
	mgorman@...e.de, vschneid@...hat.com, linux-kernel@...r.kernel.org, 
	kprateek.nayak@....com, wuyun.abel@...edance.com, youssefesmat@...omium.org, 
	tglx@...utronix.de
Subject: Re: [PATCH 00/24] Complete EEVDF

On Wed, 14 Aug 2024 at 19:18, Mike Galbraith <efault@....de> wrote:
>
> On Wed, 2024-08-14 at 18:59 +0200, Vincent Guittot wrote:
> > On Wed, 14 Aug 2024 at 18:46, Mike Galbraith <efault@....de> wrote:
> > >
> > > On Wed, 2024-08-14 at 16:34 +0200, Vincent Guittot wrote:
> > > >
> > > > While trying to test what would be the impact of delayed dequeue on
> > > > load_avg, I noticed something strange with the running slice. I have a
> > > > simple test with 2 always running threads on 1 CPU and the each thread
> > > > runs around 100ms continuously before switching to the other one
> > > > whereas I was expecting 3ms (the sysctl_sched_base_slice on my system)
> > > > between 2 context swicthes
> > > >
> > > > I'm using your sched/core branch. Is it the correct one ?
> > >
> > > Hm, building that branch, I see the expected tick granularity (4ms).
> >
> > On my side tip/sched/core switches every 4ms but Peter's sched/core,
> > which is delayed queued on top of tip/sched/core if I don't get it
> > wrong, switches every 100ms.
>
> FWIW, I checked my local master-rt tree as well, which has Peter's
> latest eevdf series wedged in (plus 4cc290c20a98 now).. it also worked
> as expected.

After looking at deadline and slice, the issue is on my tool was
trying to change the slice (an old trial for previous version) which
got clamp to 100ms.
we can forgot this, sorry for the noise

>
>         -Mike
>