linux-kernel - Re: [revert] mysql+oltp regression

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:	Mon, 11 Aug 2008 09:27:04 -0400
From:	Gregory Haskins <ghaskins@...ell.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Mike Galbraith <efault@....de>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [revert] mysql+oltp regression

Gregory Haskins wrote:
> Ingo Molnar wrote:
>> * Gregory Haskins <ghaskins@...ell.com> wrote:
>>
>>  
>>>>> Speaking of this: Another patch I submitted to you Ingo (had to do 
>>>>> with updating the load_weight inside task_setprio) seems to also 
>>>>> have this phenomenon: e.g. its technically correct but further 
>>>>> testing has revealed negative repercussions elsewhere.  So please 
>>>>> ignore that patch (or revert if you already pulled in, but I don't 
>>>>> think you have).  Ill try to look into this issue as well.
>>>>>         
>>>> ok, under which thread/subject is that? Not queued in tip/sched/* 
>>>> yet, correct?
>>>>         
>>> Here is the original thread:
>>>
>>> http://lkml.org/lkml/2008/7/3/416
>>>
>>> I do not believe you have queued it anywhere (public anyway) yet.
>>>
>>> Note I have already invalidated 1/2, and now I am retracting 2/2 as 
>>> well.  (1/2 is actually a bogus patch, 2/2 is "technically correct" 
>>> but causes ripples in the load balancer that need to be sorted out 
>>> first.
>>>     
>>
>> ok, thanks. I'm curious, what are those ripple effects? Stability or 
>> performance?
>>   
>
> Performance.  I found it while working on my pi series (which fyi I 
> should have a v2 refresh for soon, probably today...i am hoping to get 
> some review feedback from you on that as well, time permitting of 
> course ;).
>
> Basically the behavior I was observing was that kernel builds via 
> distcc would cluster all the cc1 jobs on a single core.  At first I 
> thought my pi-series was screwed up, but then I realized I had applied 
> the patch referenced above earlier in my development tree, and 
> removing it allowed pi to work fine.
>
> I found the problem with in once boot cycle with ftrace (thanks Steve!).

Hmm..Im not sure what went wrong between brain and hand above, but of 
course I meant to say ".. within one boot cycle ..", not "with in 
once".  Heh. 


>   Basically newidle balancing was always returning "no imbalance" even 
> though I had 32 cc1 threads on 1 core, and 3 idle cores.  Clearly not 
> correct!  So I think that by adjusting the load up, we throw off the 
> hysteresis built into the load averages and cause the system to 
> incorrectly think it's balanced. TBD.
>
> -Greg
>
>
>>     Ingo
>>   
>
>



Download attachment "signature.asc" of type "application/pgp-signature" (258 bytes)