Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 26 Jan 2022 20:22:52 -0500 (EST)
From:   Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To:     Paul Turner <pjt@google.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Michael Jeanson <mjeanson@efficios.com>,
        paulmck <paulmck@kernel.org>, Boqun Feng <boqun.feng@gmail.com>,
        linux-kernel <linux-kernel@vger.kernel.org>
Message-ID: <1211272108.4257.1643246572499.JavaMail.zimbra@efficios.com>
Subject: rseq vcpu_id ideas
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Thread-Index: ix/xoRPtt8dW/JcuQ/MP/FnBqGa3UA==
Thread-Topic: rseq vcpu_id ideas
Precedence: bulk

Hi Paul,

I remember our LPC discussions about your virtual cpu ids ideas, and noticed some tcmalloc code
with "prototype" fields for vcpu_id and numa node id
(https://github.com/google/tcmalloc/blob/master/tcmalloc/internal/linux_syscall_support.h#L34).

I'm currently toying with ideas very close to vcpu_ids to solve issues with overzealous
memory allocation for LTTng-UST (user-space tracer) in use-cases where containers use few
cores.

My current thinking is that we could use your vcpu_id idea, but apply it on a per-pid-namespace
basis rather than per-process. We may have to be clever with NUMA as well to ensure good NUMA
locality.

Do you have any thought about this, and perhaps some prototype rseq extension code you could
share as a starting point ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com