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]
Date:	Tue, 29 Jul 2008 10:22:51 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Andi Kleen <andi@...stfloor.org>, Mike Galbraith <efault@....de>,
	Frederik Deweerdt <deweerdt@...e.fr>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	suresh.b.siddha@...el.com, Ingo Molnar <mingo@...e.hu>
Subject: Re: BUG: unable to handle kernel NULL pointer dereference at
 00000002

On Tue, 29 Jul 2008 18:31:13 +0200
Andi Kleen <andi@...stfloor.org> wrote:

> > > A power saving feature that has a significant trade off between
> > > power and performance. 
> > 
> > do you have numbers to explain "significant tradeoff" ?
> 
> I don't have numbers, but from the theory it seems pretty clear. 
> When you e.g. have two processes with 6MB cache foot print and 
> you have two 2C CPUs with 6MB cache they will fit in cache, but 
> with power aware scheduler they won't because both processes will run
> on the single 6MB package.  With NUMA the effect is even worse because
> also the memory controllers are not used evenly.
> And there's the FSB bandwidth, but that's a secondary issue.

but if you have 2 threads that share a lot of data, it's the opposite.

Or if you have a bunch of things which are smaller than the cache... 
(and they do share, for example glibc will be largely shared).

it's not a clear heavy loss, it's one of those "depends" cases.
(which sucks)

> > 
> >  
> > > This means performance will go down. Perhaps it would be ok on
> > > battery, 
> > 
> > the illusion that power only matters on battery got buried a few
> > years ago ;)
> 
> My understanding was always that unless you're on battery power saving
> features that are enabled by default are not supposed to impact
> performance significantly. 

That's not what datacenter people say. As long as power gain is bigger
than performance loss.. they tend to want it.

Also "significantly" is extremely subjective, like in this case it can
be a win or a loss, depending.

> When the user says impacting performance
> is ok then doing that is fine of course, but not by default.

that's a fine kernel policy.

Distros will override this policy if their users tell them they're
willing to do the tradeoff.. they will pick that default. In fact..
that's a big part of their job.. 


-- 
If you want to reach me at my work email, use arjan@...ux.intel.com
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ