Re: [PATCH 0/5] SUBCPUSETS: a resource control functionality usingCPUSETS

[Paul Jackson]

Well, I suspect I don't understand yet.

Nice picture though - that gives me some idea what you mean.

Do notice that the basic rule of cpu_exclusive cpusets is that their
CPUs don't overlap their siblings.  Your Cpusets 1, 2, and 3 seem to be
marked cpu_exclusive in your picture, but all contain the same CPUs 2
and 3, overlapping each other.

I'm guessing what you are trying to draw is:

  Tasks on CPUs 0 and 1 have no resource control limits.

  Tasks on CPUs 2 and 3 have resource control limits specifying
	what percentage of the CPUs 2 and 3 is available to them.

I might draw my solution to that as:

     +-----------------------------------+
     |                                   |
  CPUSET 0                            CPUSET 1         
  sched domain A                      sched domain B   
  cpus: 0, 1                          cpus: 2, 3       
  cpu_exclusive=1                     cpu_exclusive=1
  meter_cpu=0                         meter_cpu=0
                                         |
                        +----------------+----------------+
                        |                |                |
                     CPUSET 1a        CPUSET 1b        CPUSET 1c
                     cpus: 2, 3       cpus: 2, 3       cpus: 2, 3
		     cpu_exclusive=0  cpu_exclusive=0  cpu_exclusive=0
                     meter_cpu=1      meter_cpu=1      meter_cpu=1
                     meter_cpu_*      meter_cpu_*      meter_cpu_*

The meter_cpu_* files in each of Cpusets 1a, 1b, and 1c control what
proportion of the CPU resources in that Cpuset can be used by the tasks
in that Cpuset.

If meter_cpu is false (0) then the meter_cpu_* files do not appear,
which is equivalent to allowing 100% of the CPUs in that Cpuset to
be used by the tasks in that Cpuset (and descendents, of course.)

Don't forget - this all seems like it has significant mission overlap
with CKRM.  I hate to repeat this, but the relation of your work to
CKRM needs to be understood before I am likely to agree to accepting
your work into the kernel (not that my acceptance is required; you
really just need Linus to agree, though he of course considers the
positions of others to some inscrutable degree.)

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@xxxxxxx> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/