Re: [Lse-tech] NUMA: Simple binding API, rev 0.3

[Niels C. <nc...@us...>]

Michael Hohnbaum wrote:

> A new version of the simple binding API is now available at:
>   http://lse.sourceforge.net/numa/numa_api.html
> This is an update to the original proposal by Paul McKenney.
> All comments are welcomed.

That was easy, Michael.  Looks good to me.  I have a few
questions and suggestions, though:

1. Since there is a behavior argument to the bindtomemblk(),
   setlaunch() and bindmemory() calls, I would like to know
   why one is not needed for the bindtocpu() call?  Would it
   not be useful to be able to utilize idle processors
   rather than have several processes compete for a subset
   of processors?  I'm thinking of allowing for a NOT_STRICT
   option, possibly along with others, that say whether and
   under which circumstances a process may disregard the
   (preferred) binding and where it may go.

2. What with a function to say bind a process to a set of
   processors on any one node and memory on any one (other?)
   node?  Something along the lines of:

   int bindcpumem(int cpunode, u_int cpuset,
       int memnode, u_int memset, u_int behavior);

   where a cpuset is a bitmask for the processors on a node
   regardless of the global cpu-numbering and memset is the
   same for memory.  This would permit a "job" to be moved as
   a unit of work from one node to another.  By giving -1
   arguments to cpunode and memnode you could say that you
   don't really care which node as long as the process group
   executes on processors of the same node.

3. I notice the absence of "distance".  As far as I can tell,
   the coupling to nodes is mostly another way of saying
   distance.  With all the discussion about distance in Paul
   Dorwin's topology design, maybe the binding API could be
   enhanced by using distance.  For example, my suggested
   bindcpumem() function could then be something like:

   int binddist(int node, int max_cpu_dist, int max_mem_dist,
                u_int behavior);

   where a node argument of -1 means any node.

4. The API functional specification is one thing.  What with
   the changes to data structures in the kernel, scheduler,
   system calls, etc. Is that something you have prototyped?

5. Would we not need a migrate() function or is that beyond
   the scope of the API?

- nc -