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]
Date:	Mon, 14 Jul 2014 15:51:06 +0200
From:	Peter Zijlstra <>
To:	Vincent Guittot <>
Cc:	Ingo Molnar <>,
	linux-kernel <>,
	Russell King - ARM Linux <>,
	LAK <>,
	Preeti U Murthy <>,
	Morten Rasmussen <>,
	Mike Galbraith <>,
	Nicolas Pitre <>,
	"" <>,
	Daniel Lezcano <>,
	Dietmar Eggemann <>
Subject: Re: [PATCH v3 08/12] sched: move cfs task on a CPU with higher

On Fri, Jul 11, 2014 at 05:17:44PM +0200, Vincent Guittot wrote:
> > In any case, its feels rather arbitrary to me. What about machines where
> > there's no cache sharing at all (the traditional SMP systems). This
> > thing you're trying to do still seems to make sense there.
> ok, I thought that traditional SMP systems have this flag set at core
> level. 

Yeah, with 1 core, so its effectively disabled.

> I mean ARM platforms have the flag for CPUs in the same cluster
> (which include current ARM SMP system) and the corei7 of my laptop has
> the flag at the cores level.

So I can see 'small' parts reducing shared caches in order to improve
idle performance.

The point being that LLC seems a somewhat arbitrary measure for this.

Can we try and see what happens if you remove the limit. Its always best
to try the simpler things first and only make it more complex if we have

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists