linux-kernel - Re: RT sched: cpupri_vec lock contention with def_root

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: <49249245.4000406@novell.com>
Date:	Wed, 19 Nov 2008 17:25:09 -0500
From:	Gregory Haskins <ghaskins@...ell.com>
To:	Dimitri Sivanich <sivanich@....com>
CC:	Max Krasnyansky <maxk@...lcomm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: RT sched: cpupri_vec lock contention with def_root_domain and
 no load balance

Dimitri Sivanich wrote:
> On Wed, Nov 19, 2008 at 03:25:15PM -0500, Gregory Haskins wrote:
>   
>> It sounds like the problem with my code is that "null sched domain"
>> translates into "default root-domain" which is understandably unexpected
>> by Dimitri (and myself).  Really I intended root-domains to become
>> associated with each exclusive/disjoint cpuset that is created.  In a
>> way, non-balanced/isolated cpus could be modeled as an exclusive cpuset
>> with one member, but that is somewhat beyond the scope of the
>>     
>
> Actually, at one time, that is how things were setup.  Setting the
> cpu_exclusive bit on a single cpu cpuset would isolate that cpu from
> load balancing.
>   

Re-reading my post made me realize what I said above was confusing.  The
"that" in "but that is somewhat beyond the scope" was meant to be
"explicit/direct support for the no-balance flag".  However, it perhaps
sounded like I was talking about exclusive cpusets with singleton
membership.  Exclusive cpusets are the original raison-d'etre for
root-domains. ;)

Therefore I agree that the exclusive cpuset portion should work (but
seems to be broken, thus the bug report).  My primary goal is to fix
this issue.  However, I would also like to *add* support for the
no-balance flag as a secondary goal.  Its just that this is new feature
from my perspective, so may it take some additional work to figure out
what needs to be done.  HTH and sorry for the confusion.

-Greg
>   
>> root-domain code as it stands today.  My primary concern was that
>> Dimitri reports that even creating a disjoint cpuset per cpu does not
>> yield an isolated root-domain per cpu.  Rather they all end up in the
>> default root-domain, and this is not what I intended at all.
>>
>> However, as a secondary goal it would be nice to somehow directly
>> support the "no-load-balance" option without requiring explicit
>> exclusive per-cpu cpusets to do it.  The proper mechanism (IMHO) to
>> scope the scheduler to a subset of cpus (including only "self") is
>> root-domains so I would prefer to see the solution based on that. 
>> However, today there is a rather tight coupling of root-domains and
>> cpusets, so this coupling would likely have to be relaxed a little bit
>> to get there.
>>
>> There are certainly other ways to solve the problem as well.  But seeing
>> as how I intended root-domains to represent the effective partition
>> scope of the scheduler, this seems like a natural fit in my mind until
>> its proven to me otherwise.
>>
>>     
>
> Agreed. 
>   



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