linux-kernel - Re: [PATCH 3/3] sched: Disable affine wakeups by default

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: <20091025223657.5ebc2857@infradead.org>
Date:	Sun, 25 Oct 2009 22:36:57 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Mike Galbraith <efault@....de>
Cc:	Peter Zijlstra <peterz@...radead.org>, mingo@...e.hu,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] sched: Disable affine wakeups by default

On Mon, 26 Oct 2009 06:08:54 +0100
Mike Galbraith <efault@....de> wrote:

> On Sun, 2009-10-25 at 21:52 -0700, Arjan van de Ven wrote:
> > On Mon, 26 Oct 2009 05:38:27 +0100
> > Mike Galbraith <efault@....de> wrote:
> > 
> > > On Mon, 2009-10-26 at 02:53 +0100, Peter Zijlstra wrote:
> > > > On Sun, 2009-10-25 at 23:04 +0100, Mike Galbraith wrote:
> > > > >                 if (want_affine && (tmp->flags &
> > > > > SD_WAKE_AFFINE) &&
> > > > > -                   cpumask_test_cpu(prev_cpu,
> > > > > sched_domain_span(tmp))) {
> > > > > +                               (level == SD_LV_SIBLING ||
> > > > > level == SD_LV_MC)) {
> > > > 
> > > > quick comment without actually having looked at the patch, we
> > > > should really get rid of sd->level and encode properties of the
> > > > sched domains in sd->flags.
> > > 
> > > Yeah, sounds right, while writing that, it looked kinda ugly.  I
> > > suppose arch land needs to encode cache property somehow if I
> > > really want to be able to target cache on multicore.  Booting
> > > becomes.. exciting when I tinker down there.
> > 
> > or we just use SD_WAKE_AFFINE / SD_BALANCE_WAKE for this...
> 
> I don't see how.  Oh, you mean another domain level, top level being
> cache property, and turn off when degenerating?  That looks like it'd
> be a problem, but adding SD_CACHE_SIBLING or whatnot should work.
> Problem is how to gain knowledge of whether multicores share a cache
> or not.

Actually I meant setting the SD_BALANCE_WAKE flag for the SMT and MC
domains (and then making sure that "MC" really means "shares LLC" in
the arch code), and then using this as indication in the sched code..

if you're a multicore domain you better have a shared cache.. that's
what it should mean. If it does not we should fix that.

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/