linux-kernel - Re: [patch 2/2] sched: dynticks idle load balancing

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: <20070223034309.GA21886@wotan.suse.de>
Date:	Fri, 23 Feb 2007 04:43:09 +0100
From:	Nick Piggin <npiggin@...e.de>
To:	"Siddha, Suresh B" <suresh.b.siddha@...el.com>
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org, rostedt@...dmis.org
Subject: Re: [patch 2/2] sched: dynticks idle load balancing - v2

On Thu, Feb 22, 2007 at 02:33:00PM -0800, Suresh B wrote:
> On Thu, Feb 22, 2007 at 04:26:54AM +0100, Nick Piggin wrote:
> > This is really ugly, sorry :(
> 
> hm. myself and others too thought it was a simple and nice idea.

The idea is not bad. I won't guarantee mine will be as good or better,
but I think it is sensible to try implementing the simplest approach
first, so we can get a baseline to justify more complexity against...

Your code just needs work, but if it really produces good results then
it should be able to be made into a mergeable patch.

> > My suggestion for handling this was to increase the maximum balance
> > interval for an idle CPU, and just implement a global shutdown when
> > the entire system goes idle.
> > 
> > The former should take care of the power savings issues for bare metal
> > hardware, and the latter should solve performance problems for many idle
> > SMP guests. It should take very little code to implement.
> 
> coming to max balance interval will be challenging. It needs to save
> power and at the same time respond to load changes fast enough.

Yep.

> > If that approach doesn't cut it, then at least we can have some numbers
> > to see how much better yours is so we can justify including it.
> > 
> > If you are against my approach, then I can have a try at coding it up
> > if you like?
> 
> Sure. If you can provide a patch, I will be glad to provide power and
> performance comparision numbers with both the approaches.

OK that would be good. I'll see if I can code something up by next week.

Thanks,
Nick
-
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/