Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp6891080ybi; Wed, 31 Jul 2019 23:50:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqxO+kgWm05GC2FvS/vlqmoL5xAUQFIm5iJ+xM9b2HwVZYK1u6BmET7X3xnQaEg/6kgMbh99 X-Received: by 2002:a62:ae02:: with SMTP id q2mr50329283pff.1.1564642205073; Wed, 31 Jul 2019 23:50:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564642205; cv=none; d=google.com; s=arc-20160816; b=B3c0MRlvgZ1vp66WFHU0ZZZYd3F7YPpdYjuklS5OVYyc9rYTrUP8Kbbvo7/J5eYpp5 zn5k+eKO5eiy/JOapYNM6MXScNKDgEEZw0FTX5shYPT5Wv/iYxxu9KCBvPWhfCh2Cab2 xZbs8zSO4PJHGn9yJLDqRetWay0+v7nPRMbZ3w2iQ6+pt2KXxs4w9ScyfC1Gk5vhVSRa q8XbIwCWak176PFSoj9zy+T1L8/Y/FU8RTcetbHDIv9TKU3vX1whqDxElBG1rGhBS0mO A16sb0nF5oCLpOYUnV/KWT7vW1BnTMeQbLDncUxvZFaQhqWPRIH2CsMOjuqqhdnHDuR2 OiFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=tf25eB4gKEG2DoLULylEkmj8cEUxOs/f3WvtwUVArms=; b=MkSmBuP4MOsSj+c0HVcIfToZhAndkdgrRut+0PWXEuCVzzFtgVhuLYR3bjQCu7Byve /Y4379wABo3DUmtEM2yF/yYWFG7nTwSrGr6/lc7YugHNYkADj42wqTzzq9Fozasy17cG TCATupQvNX+9yH58E9tbO6MIKkaexnnsjY9g55spAsMXRNA5eQgN+rqHgCWL3+Cqzsx2 56Sb/O6OAmdxF6JvZBJY/TjPZeQtAMgAL9FEuFeTYC0EnEVoiOSp9Ks+yrpD72bmdncr 7W5AtoK1i96eI5SfYOrbvvJjz7MWVemrxQcAK++fEnX8SFbaj0NQdqbGsIfU+Kp5NHRa nhkw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t19si34401481pfe.94.2019.07.31.23.49.49; Wed, 31 Jul 2019 23:50:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730506AbfHAGsj (ORCPT + 99 others); Thu, 1 Aug 2019 02:48:39 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:34108 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730472AbfHAGsh (ORCPT ); Thu, 1 Aug 2019 02:48:37 -0400 Received: from pd9ef1cb8.dip0.t-ipconnect.de ([217.239.28.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ht4sm-00078d-HJ; Thu, 01 Aug 2019 08:48:12 +0200 Date: Thu, 1 Aug 2019 08:48:10 +0200 (CEST) From: Thomas Gleixner To: Andy Lutomirski cc: Dmitry Safonov , LKML , Dmitry Safonov <0x7f454c46@gmail.com>, Andrei Vagin , Adrian Reber , Andrei Vagin , Arnd Bergmann , Christian Brauner , Cyrill Gorcunov , "Eric W. Biederman" , "H. Peter Anvin" , Ingo Molnar , Jann Horn , Jeff Dike , Oleg Nesterov , Pavel Emelyanov , Shuah Khan , Vincenzo Frascino , Linux Containers , criu@openvz.org, Linux API , X86 ML Subject: Re: [PATCHv5 28/37] x86/vdso: Enable static branches for the timens vdso In-Reply-To: Message-ID: References: <20190729215758.28405-1-dima@arista.com> <20190729215758.28405-29-dima@arista.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 31 Jul 2019, Andy Lutomirski wrote: > On Mon, Jul 29, 2019 at 2:58 PM Dmitry Safonov wrote: > > As it has been discussed on timens RFC, adding a new conditional branch > > `if (inside_time_ns)` on VDSO for all processes is undesirable. > > > > Addressing those problems, there are two versions of VDSO's .so: > > for host tasks (without any penalty) and for processes inside of time > > namespace with clk_to_ns() that subtracts offsets from host's time. > > > > The timens code in vdso looks like this: > > > > if (timens_static_branch_unlikely()) { > > clk_to_ns(clk, ts); > > } > > I'm confused. Now we effectively have *three* versions: the vDSO > without timens, and vDSO with timens but with it switched off, and the > vDSO with timens on. This seems like too much. The problem is that if you have a single VDSO, then omce one process joins a time namespace _ALL_ other processes get an extra conditional with at least one extra cache line as a bonus. This has been discussed at Plumbers last year and the agreement was to create VDSO plain (no namespace support) and VDSO extra (namespace support). The performance hit of the conditional + one etra cache line for tasks which do not use a time name space is measurable. That also avoids the whole mess of dealing with the static branch being flipped. The time name space property is determined on fork/exec _before_ anything can touch the VDSO and depending on it the approriate version of the VDSO is loaded. Thanks, tglx