Re: [revert] mysql+oltp regression
From: Gregory Haskins
Date: Mon Aug 11 2008 - 08:30:27 EST
Ingo Molnar wrote:
* Mike Galbraith <efault@xxxxxx> wrote:
Greetings,
During regression testing of tip/sched/clock fixes, a regression in
low client count throughput turned up, which I traced this back to the
commit below. I don't see anything wrong with it, but suspect that it
is preventing client/server pairs from staying together on the same
CPU as buddies, which mysql definitely likes quite a lot. (I suspect
that this is the case, because I've seen this same performance curve
while tinkering with wakeup affinity and breaking it all to pieces;)
Changelog and test results below in case nobody sees a problem with
the commit itself.
i've applied your fix to tip/sched/urgent for the time being, thanks
Mike for tracking it down. We can re-try newer iterations of Greg's
patch in tip/sched/devel.
Hmm.. The patch still looks correct afaict. I fear we are just
papering over some other issue by reverting it, but I will try to see if
I can track this down. We will, of course, now be skipping trying to
balance the (effectively random) last task in the queue which may or may
not result in better performance on sheer luck instead of algorithmic
intelligence. This makes me nervous.
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.
-Greg
Attachment:
signature.asc
Description: OpenPGP digital signature