Re: [Lse-tech] New version of simple-binding NUMA API on sourceforge...

[Paul J. <pj...@en...>]

A couple of weeks ago, Martin Bligh objected to the choice
of terms "physical" and "logical" for cpu and memory numbers
in the CpuMemSets design note:

On Thu, 11 Oct 2001, Martin J. Bligh wrote:
> But my main objection is that switching the terminology
> half way up is really confusing, especially for those of
> us who have to work with hardware dependant and higer level
> code. Thus I have physical apicids, logical apicids, a cpuid
> that you're calling both physical and logical depending where
> I'm standing, and a logical cpuid that's not the same as the
> other logical cpuid.


I recant.

After taking further grief (in his gentle way) from Jack Steiner
on this same issue, I have decided to change the terms to
"system" and "application".

The system numbering is that used by the kernel in such places
    as the scheduler and allocator.  It typically numbers all
    the cpu and memory in the system.  On our SGI SN hardware,
    for example, what we call the compact node id will be used
    as the CpuMemSet system number for memory nodes.

The application numbering includes just the cpu and memory
    available to the specified application.  It is that presented
    to an application via the CpuMemMap, and used in specifying
    CpuMemSets.

This is a straight renaming:

    physical ==> system
    logical  ==> application

This change is essentially a change from _relative_ (to where
you stand) names such as "physical" and "logical", to more
_absolute_ names "system" and "application".  This should help
both system programmers, such as Martin and Jack, as well as
application programmers who might be coding to this API, better
understand the distinction.

Does this help, Martin?

Thanks, Martin and Jack.


                          I won't rest till it's the best ...
                          Manager, Linux Scalability
                          Paul Jackson <pj...@sg...> 1.650.933.1373