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: <47D83858.4030806@qualcomm.com>
Date:	Wed, 12 Mar 2008 13:08:56 -0700
From:	Max Krasnyanskiy <maxk@...lcomm.com>
To:	Paul Jackson <pj@....com>
CC:	menage@...gle.com, mingo@...e.hu, a.p.zijlstra@...llo.nl,
	linux-kernel@...r.kernel.org
Subject: Re: boot cgroup questions

Paul Jackson wrote:
> Max wrote:
>> I was talking about running on the _cpus_ that belong to the "sets A and B but 
>> not C" and not that a task must belong to more than one cpuset.
> 
> This doesn't make sense to me.
> 
> If a task is to run on the CPUs in both sets A and B, then it has to be
> in both those cpusets, which isn't allowed, or in some super set of both
> A and B (that is, in this example, in the top cpuset), which doesn't
> restrict the task to just A or B or their union.
> 
> I have no idea what distinction you are seeing between what _cpus_ a task
> can run on, and what cpuset it belongs to.

Paul, we are in 100% agreement here about the tasks. All I'm saying is that 
the same exact thing applies to the irqs. Again let me try your example.

Suppose we have
	/dev/cpuset/A
	/dev/cpuset/B
	/dev/cpuset/C

Now suppose that for whatever reason I must run task1 on the cpus that belong 
to sets A and B but not C. The only way to do that with cpusets is

	/dev/cpuset/X
         	  |-- A
	          `-- B
	/dev/cpuset/C

i.e. create parent cpuset X and assign task1 into cpuset X.
Of course if A and B are not cpu_exclusive then X does not have to be their 
parent.

Makes sense so far ?

Now the same exact thing can be said about the irqs. If I need to assign irq1 
to the cpus in sets A and B but not C I have to create set X that is the union 
of A and B, and assign irq1 to the set X.

This is what I meant by "deeper hierarchies" in the earlier emails.

Did I do a better job explaining this time :) ?

Max






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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ