Messages in this thread | | | Date | Mon, 21 Nov 2022 14:52:35 -0500 | Subject | Re: [PATCH v5 08/24] sched: Introduce per memory space current virtual cpu id | From | Mathieu Desnoyers <> |
| |
On 2022-11-21 14:00, Mathieu Desnoyers wrote: > On 2022-11-17 16:15, Sean Christopherson wrote: >> On Thu, Nov 17, 2022, Mathieu Desnoyers wrote: >>> On 2022-11-17 14:10, Sean Christopherson wrote: >>>> On Thu, Nov 17, 2022, Mathieu Desnoyers wrote: >>>>> On 2022-11-14 15:49, Sean Christopherson wrote: >>>>>> On Fri, Nov 11, 2022, Mathieu Desnoyers wrote: >>>>>>> On 2022-11-10 23:41, Andy Lutomirski wrote: >>>>>>>> On Thu, Nov 3, 2022 at 1:05 PM Mathieu Desnoyers >>>>>>>> <mathieu.desnoyers@efficios.com> wrote: >>>>>>>> Also, in my mind "virtual cpu" is vCPU, which this isn't. Maybe >>>>>>>> "compacted cpu" or something? It's a strange sort of concept. >>>>>>> >>>>>>> I've kept the same wording that has been introduced in 2011 by >>>>>>> Paul Turner >>>>>>> and used internally at Google since then, although it may be >>>>>>> confusing if >>>>>>> people expect kvm-vCPU and rseq-vcpu to mean the same thing. Both >>>>>>> really end >>>>>>> up providing the semantic of a virtually assigned cpu id (in >>>>>>> opposition to >>>>>>> the logical cpu id on the system), but this is much more involved >>>>>>> in the >>>>>>> case of KVM. >>>>>> >>>>>> I had the same reaction as Andy. The rseq concepts don't worry me >>>>>> so much as the >>>>>> existence of "vcpu" in mm_struct/task_struct, e.g. >>>>>> switch_mm_vcpu() when switching >>>>>> between KVM vCPU tasks is going to be super confusing. Ditto for >>>>>> mm_vcpu_get() >>>>>> and mm_vcpu_put() in the few cases where KVM currently does >>>>>> mmget()/mmput(). >>>>> >>>>> I'm fine with changing the wording if it helps make things less >>>>> confusing. >>>>> >>>>> Should we go for "compact-cpu-id" ? "packed-cpu-id" ? Other ideas ? >>>> >>>> What about something like "process-local-cpu-id" to capture that the >>>> ID has meaning >>>> only within the associated address space / process? >>> >>> Considering that the shorthand for "memory space" is "VM" in e.g. >>> "CLONE_VM" >> >> No objection from me for "vm", I've already had to untrain myself and >> remember >> that "vm" doesn't always mean "virtual machine" :-) >> >>> clone(2) flags, perhaps "vm-cpu-id", "vm-local-cpu-id" or >>> "per-vm-cpu-id" ? >> >> I have a slight preference for vm-local-cpu-id, but any of 'em work >> for me. > > Taking a step back wrt naming (because if I do a name change across the > series, I want it to be the last time I do it): > > - VM (kvm) vs vm_ (rseq) is confusing. > - vCPU (kvm) vs vcpu (rseq) is confusing. > > I propose "Address Space Concurrency ID". This indicates that those IDs > are really just tags assigned uniquely within an address space for each > thread running concurrently (and only while they are running). > > Then the question that arises is whether the abbreviation presented to > user-space should be "mm_cid" (as would be expected from an internal > implementation perspective) or "as_cid" (which would match the name > exposed to user-space) ?
Or it could be "Memory Map Concurrency ID" (mm_cid) to have matching abbreviation and naming. The notion of a "memory map" seems to be seen in a few places in man pages, and there are event tools to explore process memory maps (pmap(1)).
Thanks,
Mathieu
> > Thanks, > > Mathieu >
-- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com
| |