From: Gregory Haskins <ghaskins@novell.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Mike Galbraith <efault@gmx.de>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [revert] mysql+oltp regression
Date: Mon, 11 Aug 2008 09:19:42 -0400 [thread overview]
Message-ID: <48A03C6E.60303@novell.com> (raw)
In-Reply-To: <20080811131400.GA909@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]
Ingo Molnar wrote:
> * Gregory Haskins <ghaskins@novell.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!). 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
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2008-08-11 13:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-11 11:32 [revert] mysql+oltp regression Mike Galbraith
2008-08-11 11:43 ` Ingo Molnar
2008-08-11 12:27 ` Gregory Haskins
2008-08-11 12:48 ` Ingo Molnar
2008-08-11 12:51 ` Ingo Molnar
2008-08-11 13:03 ` Gregory Haskins
2008-08-11 13:14 ` Ingo Molnar
2008-08-11 13:19 ` Gregory Haskins [this message]
2008-08-11 13:27 ` Gregory Haskins
2008-08-11 13:31 ` Ingo Molnar
2008-08-11 13:29 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48A03C6E.60303@novell.com \
--to=ghaskins@novell.com \
--cc=a.p.zijlstra@chello.nl \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox