linux-kernel - Re: power increase issue on light load

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: <1308876099.23204.124.camel@debian>
Date:	Fri, 24 Jun 2011 08:41:39 +0800
From:	"Alex,Shi" <alex.shi@...el.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	"ncrao@...gle.com" <ncrao@...gle.com>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"Chen, Tim C" <tim.c.chen@...el.com>,
	"Li, Shaohua" <shaohua.li@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	len.brown@...el.com
Subject: Re: power increase issue on light load

On Thu, 2011-06-23 at 17:02 +0800, Peter Zijlstra wrote:
> On Thu, 2011-06-23 at 10:43 +0800, Alex,Shi wrote:
> > commit c8b281161dfa4bb5d5be63fb036ce19347b88c63 causes light load
> > benchmark use more than 10% system power on platform NHM-EP and laptop
> > Thinkpad T410 etc. The benchmarks are specpower and bltk office. 
> > 
> > I tried to track this issue, but only find deep C sate time reduced
> > much, about from 90% to 30~40%, the C0 or C1 state increase much on
> > different machines. 
> > 
> > Powertop just hints RES interrupts has a bit more. but when I try "perf
> > probe native_smp_send_reschedule". I didn't find much. 
> > 
> > I also checked the /proc/schedstat, just can sure the load_balance was
> > called a bit more frequency. but pull_task() was called really rare. 
> > 
> > 
> > The following are the /proc/schedstat increased number in about 300' when do bltk-office. 
> > The getting command is here:
> > #on a 16 LCPU system, with 3 level domain, 0,1,2, so all domain number
> > is 48, the domain statistic number is 2 + 36, so fs=38,
> > 
> > $cat /proc/schedstat > schedstat ; sleep x ; cat /proc/schedstat >>
> > schedstat ; cat schedstat | grep domain | sed '49 i \\n' |  awk -v fs=38
> > 'BEGIN { RS=""; FS=" " } { if ( NR ==1) for (i=0; i<NF; i++)
> > { value1[i]=$i ; } ;  if ( NR ==2) for (i=0; i<NF; i++) { value2[i]=
> > $i } } END {ORS=" ";  for (i=0;i<NF;i++){ if (i%fs == 0)  ll="\n"; else
> > ll=""; print value2[i] - value1[i]  ll  };  print "\n" }'
> 
> /proc/schedstat is already a massive pain to interpret and then you go
> and mangle things even more and expect me to try and understand that
> crap? I don't think so, life is too short.
> 
> > BTW, the imbalance increasing is due to the SCALE increase about 1024. 
> 
> > Any ideas of this? 
> 
> What happens if you try something like the below. Increased imbalance
> might lead to more load-balance action, which might lead to more task
> migration/waking up of cpus etc.
> 
> If the below makes any difference, Nikhil's changes have a funny that
> needs to be caught.

Yes, it most remove the commit effect, So the power recovered. 

In fact the only suspicious I found is large imbalance, but that it is
the commit want to...



--
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/