linux-kernel - Re: [PATCH 3/3] Subject: SCHED - Use a 2-d bitmap for searching lowest-pri CPU

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] [day] [month] [year] [list]

Message-Id: <4756642F.BA47.005A.0@novell.com>
Date:	Wed, 05 Dec 2007 08:41:19 -0500
From:	"Gregory Haskins" <ghaskins@...ell.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	<rostedt@...dmis.org>, <linux-kernel@...r.kernel.org>,
	<linux-rt-users@...r.kernel.org>
Subject: Re: [PATCH 3/3] Subject: SCHED - Use a 2-d bitmap for
	searching lowest-pri CPU

>>> On Wed, Dec 5, 2007 at  6:44 AM, in message <20071205114438.GC6143@...e.hu>,
Ingo Molnar <mingo@...e.hu> wrote: 

> * Gregory Haskins <ghaskins@...ell.com> wrote:
> 
>> However, that said, Steven's testing work on the mainline port of our 
>> series sums it up very nicely, so I will present that in lieu of 
>> digging up my -rt numbers unless you specifically want them too.  Here 
>> they are:
> 
> i'm well aware of Steve's benchmarking efforts, but i dont think he's 
> finished with it and i'll let him present the results once he wants to 
> announce them. I asked about the effects of the "2-d" patch in isolation 
> and i'm not sure the numbers show that individual patch in action.

Ah, sorry if I was not clear.  What I was trying to show was that you can compare "gh" to "cpupri" to see the effects of the 2-d patch in isolation (*) in Steven's tests.  I believe it shows a positive impact on some tests, and a negligible impact on some tests.  As long as we dont have a regression somewhere, I am happy :)

(*) Yes, "cpupri" in this test also has patches 21-22 (root-domain).  However, note that Steven is not configuring cpusets, and therefore the root-domain code is effectively marginalized in this data.  Its not a pure isolation, no.  But the results of my tests with *true* isolation present similar characteristics, so I felt they were representative.

> 
> in any case, you are preaching to the choir, i wrote the first 
> rt-overload code and it's been in -rt forever so it's not like you need 
> to sell me the concept ;-) But upstream quality requirements are 
> different from -rt and we need to examine all aspects of scheduling, not 
> just latency. 

Understood and agree.  I designed the subsystem with the overall system in mind, so hopefully that is reflected in the numbers and the review comments that come out of this. :)

>In any case, i'll wait for the rest of Steve's numbers.

Sounds good.  Ill try to dig up my 4/8-way numbers as well for another data point.

Thanks for taking the time to review all this stuff.  I know you are swamped these days.

-Greg

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