linux-kernel - Re: [PATCH V3 1/2] sched: Reduce the default slice to avoid tasks getting an extra tick

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: <20250210012931.ym337oexdcjmwwzv@airbuntu>
Date: Mon, 10 Feb 2025 01:29:31 +0000
From: Qais Yousef <qyousef@...alina.io>
To: zihan zhou <15645113830zzh@...il.com>
Cc: bsegall@...gle.com, dietmar.eggemann@....com, juri.lelli@...hat.com,
	linux-kernel@...r.kernel.org, mgorman@...e.de, mingo@...hat.com,
	peterz@...radead.org, rostedt@...dmis.org,
	vincent.guittot@...aro.org, vschneid@...hat.com
Subject: Re: [PATCH V3 1/2] sched: Reduce the default slice to avoid tasks
 getting an extra tick

On 02/08/25 15:53, zihan zhou wrote:
> The old default value for slice is 0.75 msec * (1 + ilog(ncpus)) which
> means that we have a default slice of
> 0.75 for 1 cpu
> 1.50 up to 3 cpus
> 2.25 up to 7 cpus
> 3.00 for 8 cpus and above.

I brought the topic up of these magic values with Peter and Vincent in LPC as
I think this logic is confusing. I have nothing against your patch, but if the
maintainers agree I am in favour of removing it completely in favour of setting
it to a single value that is the same across all systems.

I do think 1ms makes more sense as a default value given how modern workloads
need faster responsiveness across the board. But keeping it 3ms to avoid much
disturbance would be fine. We could also make it equal to TICK_MSEC (this
define doesn't exist) if it is higher than 3ms.

Do you use HZ=100 by the way? If yes, are you able to share the reasons? This
configuration is too aggressive and bad for latencies and I doubt this tweak of
the formula will make things better to them anyway.