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: <4924762B.8000108@novell.com>
Date:	Wed, 19 Nov 2008 15:25:15 -0500
From:	Gregory Haskins <ghaskins@...ell.com>
To:	Max Krasnyansky <maxk@...lcomm.com>
CC:	Dimitri Sivanich <sivanich@....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

Max Krasnyansky wrote:
> Gregory Haskins wrote:
>   
>> If you tried creating different cpusets and it still had them all end up
>> in the def_root_domain, something is very broken indeed.  I will take a
>> look.
>>     
>
> I beleive that's the intended behaviour.
Heh...well, as the guy that wrote root-domans, I can definitively say
that is not the behavior that I personally intended ;)

>  We always put cpus that are not
> balanced into null sched domains. This was done since day one (ie when
> cpuisol= option was introduced) and cpusets just followed the same convention.
>   

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

Regards,
-Greg

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