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]

Message-ID: <48A03049.202@novell.com>
Date:	Mon, 11 Aug 2008 08:27:53 -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

Ingo Molnar wrote:
> * Mike Galbraith <efault@....de> 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

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