From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5241C433FE for ; Mon, 10 Oct 2022 13:04:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229564AbiJJNEv (ORCPT ); Mon, 10 Oct 2022 09:04:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229612AbiJJNEu (ORCPT ); Mon, 10 Oct 2022 09:04:50 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EA8E03890 for ; Mon, 10 Oct 2022 06:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1665407079; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/EKUr7eRGSpHO08SnSJlFsYYLyW7vfd3DLTPqPH/Gog=; b=VjOs6OnYF9XlfR/DoqLf0wUiFnGTIXWSV5jvGe4yQ/1JKZPSk4u8tUQCKqnxRKhWHu1SuJ 2bVZ9I1JtB2YnZQDGsu0LlbVTtWZ+C3iGGIP7X47BBXT4zuOk/TCrAnoYTark20rZdgdoW YGiT0Ef75FRYJ7DJIUk0ndZnOrdt0gQ= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-448-pcK5r2phP4KyPBixilkzJw-1; Mon, 10 Oct 2022 09:04:35 -0400 X-MC-Unique: pcK5r2phP4KyPBixilkzJw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D6C30101CC6B; Mon, 10 Oct 2022 13:04:34 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.124]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D60D42157F41; Mon, 10 Oct 2022 13:04:30 +0000 (UTC) From: Florian Weimer To: Mathieu Desnoyers Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, Thomas Gleixner , "Paul E . McKenney" , Boqun Feng , "H . Peter Anvin" , Paul Turner , linux-api@vger.kernel.org, Christian Brauner , David.Laight@ACULAB.COM, carlos@redhat.com, Peter Oskolkov , Alexander Mikhalitsyn Subject: Re: [PATCH v4 00/25] RSEQ node id and virtual cpu id extensions References: <20220922105941.237830-1-mathieu.desnoyers@efficios.com> Date: Mon, 10 Oct 2022 15:04:29 +0200 In-Reply-To: <20220922105941.237830-1-mathieu.desnoyers@efficios.com> (Mathieu Desnoyers's message of "Thu, 22 Sep 2022 06:59:15 -0400") Message-ID: <8735bv25k2.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org * Mathieu Desnoyers: > Extend the rseq ABI to expose a NUMA node ID and a vm_vcpu_id field. > > The NUMA node ID field allows implementing a faster getcpu(2) in libc. > > The virtual cpu id allows ideal scaling (down or up) of user-space > per-cpu data structures. The virtual cpu ids allocated within a memory > space are tracked by the scheduler, which takes into account the number > of concurrently running threads, thus implicitly considering the number > of threads, the cpu affinity, the cpusets applying to those threads, and > the number of logical cores on the system. Do you have some code that shows how the userspace application handshake is supposed to work with the existing three __rseq_* symbols? Maybe I'm missing something. >From an application perspective, it would be best to add 8 more shared bytes in use, to push the new feature size over 32. This would be clearly visible in __rseq_size, helping applications a lot. Alternatively, we could sacrifice a bit to indicate that the this round of extensions is present. But we'll need another bit to indicate that the last remaining 4 bytes are in use, for consistency. Or come up with something to put their today. The TID seems like an obvious choice. If we want to the 8 more bytes route, TID and PID should be uncontroversal? The PID cache is clearly something that userspace likes, not just as a defeat device for the old BYTE benchmark. Thanks, Florian