Received: by 10.192.165.156 with SMTP id m28csp1852066imm; Thu, 12 Apr 2018 04:46:38 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/7F1QRwr9Yk70mP8knpvuiQGmq0gC9jbjEzX4TGJ9GQn9MqPLRrVJf3opkzzPakVp4YYzI X-Received: by 2002:a17:902:9a96:: with SMTP id w22-v6mr636946plp.209.1523533598637; Thu, 12 Apr 2018 04:46:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523533598; cv=none; d=google.com; s=arc-20160816; b=B19bf7bqpy8g7807oz/Pv8BmsPNnJhKEw5nnZtegHTvigfUOr0OdniTIpGvEX64i3x H2RKXwy7Lcpy7YuRi9GfLdu+ZmAg9kxHuCavNIpGSHL03jY0x0mnWqvgv+Dk0D1301o2 FxnlN5UBHEqkwbO72V1YEvR3vnICXx6b5I5Ydj0BEKNV/zWXe+M5eHiHctgWVK9IltEi XPeiblas7YTtrNCaPlnOA6zKaQqnRosuW1krEbq8XDqb6SDUdjb2WXoTSZajjwC2reqN MJesgyCyOY80qz4a/OfTQjiF2nf1ppww8EUcZtuhlA2BDwRT1YkZQ83HpkaZF9sqIfzz WxsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:reply-to:mime-version:dkim-signature :arc-authentication-results; bh=zJ281mv9+BvhBjjRTF7irCNEGYMo6FdSAnbIUe0Ds4Q=; b=CFU6ymrzxlY/I7ReYAZb7+ccUvYsfjvkOvD2AUnojKwgV1QxjFMJYS1/FBHnVZ5y2P K7g64yeSy4OtG7jHPXpBySp8OEb9M3rkedfns7EeVb5sGXiaECy1E+wN6c/pUrEqStYL IMyH+AyjvU+N/OBGe3sBXkbKVLLmJPQuL7wVDmB5gAZ+LzhZu7r/dLjWgPslOL+7F7yC MHAG6k+YEHWTYhoGrOxJH8qMe4sn+rUYme9XeZXcGlBBukXErC1dqH/cT6XaP4A73tfB BvM89GT6yzavxVWpeX0b6FFH0C/XXpODDfj8OIMql+uzdbRd4RRiEQd8vibng3qkuFh2 WWPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=nq9+DTZT; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k6si2146148pgn.599.2018.04.12.04.46.01; Thu, 12 Apr 2018 04:46:38 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=nq9+DTZT; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751953AbeDLLnT (ORCPT + 99 others); Thu, 12 Apr 2018 07:43:19 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:38674 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750763AbeDLLnR (ORCPT ); Thu, 12 Apr 2018 07:43:17 -0400 Received: by mail-wm0-f65.google.com with SMTP id i3so9032038wmf.3; Thu, 12 Apr 2018 04:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zJ281mv9+BvhBjjRTF7irCNEGYMo6FdSAnbIUe0Ds4Q=; b=nq9+DTZTyhai2PBWqWU6IhAvVsGPzUC5+086W2NRxRmPifc/ZVWkCr9TO01bAH8pPt b2t0MO2zBel3IICLQuOhyTzUZIP73ER55ZCz4YGfSedaHou9d8c7SMAXjyhYgncM7/DD yQ3TyMJ6vSXvc9hW3GJlzes74llctbuyNGq7CU+uBQKRuk67U0j6tB/umINevwbOGO77 SZQprWWe5tncGN5/wBvVNp4/ZvD07paBxYIxKtsM8KNXyMR2ZN3zBRdNS282+JWHLbeg D+WESemf4UzeoRbFsr7o5UGukoah4cFBaWp4N197MCMO5u6e9CC8ORza7nkRSEGZ8U3T GtBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=zJ281mv9+BvhBjjRTF7irCNEGYMo6FdSAnbIUe0Ds4Q=; b=Eo/R/4w128HWfIbbE8VDWTh8Z5aThtwhGr/r0xyhRfxEsUZRLNMhFSo4/fet+Ib6Vv TMa+/LNtbV56ixaV8cliVKwR8v1KGmqqVncWhv/dC+5HGsOq1bwdQtd0onKnVYwijaLi W9CM5p69FsVBOvdQJAQ8A2U+B2R6vGq8NclOCAa29hGtT4DAEJKTv/YwHDWcIg6GoN8v BBG+sw+QWk2ngE8iTkPdVIq64gnsE41HIk75ywBvuRhtztm+N+Z9G+VN5Kk+JJipi5V4 lwM4uOtaKVS7R3xmcZdBTAV2IRCKmz8/g87nVvS2KILZNhXn9IQ/w9ZALVxaAQKaOtwu q6ug== X-Gm-Message-State: ALQs6tCXpUKWjcGXbFEEHLZtlZeNA2uvf7AqyLrDfAEHFkx5L50WCA0r wTDlY1r+QeSEjznS9mRSyyh6s+ZH/hlV6IYIHyc= X-Received: by 10.80.142.174 with SMTP id w43mr14527589edw.140.1523533395621; Thu, 12 Apr 2018 04:43:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.184.29 with HTTP; Thu, 12 Apr 2018 04:42:55 -0700 (PDT) Reply-To: mtk.manpages@gmail.com In-Reply-To: <20180212195549.11485-1-mathieu.desnoyers@efficios.com> References: <20180212195549.11485-1-mathieu.desnoyers@efficios.com> From: "Michael Kerrisk (man-pages)" Date: Thu, 12 Apr 2018 13:42:55 +0200 Message-ID: Subject: Re: [PATCH manpages] membarrier.2: New membarrier commands introduced in 4.16 To: Mathieu Desnoyers Cc: lkml , Linux API , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , Andy Lutomirski , "Paul E . McKenney" , Boqun Feng , Andrew Hunter , Maged Michael , Avi Kivity , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Dave Watson , "H . Peter Anvin" , Andrea Parri , Russell King , Greg Hackmann , Will Deacon , David Sehr Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Mathieu, On 12 February 2018 at 20:55, Mathieu Desnoyers wrote: > Document the following membarrier commands introduced in 4.16: > - MEMBARRIER_CMD_GLOBAL_EXPEDITED (the old enum label > MEMBARRIER_CMD_SHARED is now an alias to preserve header backward > compatibility), > - MEMBARRIER_CMD_GLOBAL_EXPEDITED, > - MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED, > - MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE, > - MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE. > > Signed-off-by: Mathieu Desnoyers > CC: Michael Kerrisk > CC: Ingo Molnar > CC: Peter Zijlstra > CC: Thomas Gleixner > --- > man2/membarrier.2 | 73 ++++++++++++++++++++++++++++++++++++++++++++++--------- > 1 file changed, 62 insertions(+), 11 deletions(-) > > diff --git a/man2/membarrier.2 b/man2/membarrier.2 > index c47bc875a..e878301ca 100644 > --- a/man2/membarrier.2 > +++ b/man2/membarrier.2 > @@ -80,7 +80,7 @@ This command is always supported (on kernels where > .BR membarrier () > is provided). > .TP > -.B MEMBARRIER_CMD_SHARED > +.B MEMBARRIER_CMD_GLOBAL " (since Linux 4.16)" > Ensure that all threads from all processes on the system pass through a > state where all memory accesses to user-space addresses match program > order between entry to and return from the > @@ -88,7 +88,30 @@ order between entry to and return from the > system call. > All threads on the system are targeted by this command. > .TP > -.BR MEMBARRIER_CMD_PRIVATE_EXPEDITED " (since Linux 4.14)" > +.B MEMBARRIER_CMD_GLOBAL_EXPEDITED " (since Linux 4.16)" > +Execute a memory barrier on all running threads of all processes which > +previously registered with > +.BR MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED . > +Upon return from system call, the caller thread is ensured that all > +running threads have passed through a state where all memory accesses to > +user-space addresses match program order between entry to and return > +from the system call (non-running threads are de facto in such a state). > +This only covers threads from processes which registered with > +.BR MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED . > +Given that registration is about the intent to receive the barriers, it > +is valid to invoke > +.BR MEMBARRIER_CMD_GLOBAL_EXPEDITED > +from a non-registered process. > +.IP > +The "expedited" commands complete faster than the non-expedited ones; > +they never block, but have the downside of causing extra overhead. > +.TP > +.B MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED " (since Linux 4.16)" > +Register the process intent to receive > +.BR MEMBARRIER_CMD_GLOBAL_EXPEDITED > +memory barriers. > +.TP > +.B MEMBARRIER_CMD_PRIVATE_EXPEDITED " (since Linux 4.14)" > Execute a memory barrier on each running thread belonging to the same > process as the current thread. > Upon return from system call, the calling > @@ -103,9 +126,29 @@ they never block, but have the downside of causing extra overhead. > A process needs to register its intent to use the private > expedited command prior to using it. > .TP > -.BR MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED " (since Linux 4.14)" > +.B MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED " (since Linux 4.14)" > Register the process's intent to use > -.BR MEMBARRIER_CMD_PRIVATE_EXPEDITED . > +.B MEMBARRIER_CMD_PRIVATE_EXPEDITED . > +.TP > +.B MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE " (since Linux 4.16)" > +In addition to provide memory ordering guarantees described in > +.BR MEMBARRIER_CMD_PRIVATE_EXPEDITED , > +ensure the caller thread, upon return from system call, that all its > +running threads siblings have executed a core serializing instruction. > +This only covers threads from the same process as the caller thread. > +The "expedited" commands complete faster than the non-expedited ones, > +they never block, but have the downside of causing extra overhead. A > +process needs to register its intent to use the private expedited sync > +core command prior to using it. > +.TP > +.B MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE " (since Linux 4.16)" > +Register the process intent to use > +.BR MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE . > +.TP > +.B MEMBARRIER_CMD_SHARED > + Alias to > +.BR MEMBARRIER_CMD_GLOBAL . > +Provided for header backward compatibility. > .PP > The > .I flags > @@ -137,10 +180,14 @@ The pair ordering is detailed as (O: ordered, X: not ordered): > On success, the > .B MEMBARRIER_CMD_QUERY > operation returns a bit mask of supported commands, and the > -.B MEMBARRIER_CMD_SHARED , > +.B MEMBARRIER_CMD_GLOBAL , > +.B MEMBARRIER_CMD_GLOBAL_EXPEDITED , > +.B MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED , > .B MEMBARRIER_CMD_PRIVATE_EXPEDITED , > -and > .B MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED , > +.B MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE , > +and > +.B MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE > operations return zero. > On error, \-1 is returned, > and > @@ -163,10 +210,14 @@ set to 0, error handling is required only for the first call to > is invalid, or > .I flags > is nonzero, or the > -.BR MEMBARRIER_CMD_SHARED > +.BR MEMBARRIER_CMD_GLOBAL > command is disabled because the > .I nohz_full > -CPU parameter has been set. > +CPU parameter has been set, or the > +.BR MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE > +and > +.BR MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE > +commands are not implemented by the architecture. > .TP > .B ENOSYS > The > @@ -294,9 +345,9 @@ init_membarrier(void) > return \-1; > } > > - if (!(ret & MEMBARRIER_CMD_SHARED)) { > + if (!(ret & MEMBARRIER_CMD_GLOBAL)) { > fprintf(stderr, > - "membarrier does not support MEMBARRIER_CMD_SHARED\\n"); > + "membarrier does not support MEMBARRIER_CMD_GLOBAL\\n"); > return \-1; > } > > @@ -315,7 +366,7 @@ static void > slow_path(int *read_a) > { > b = 1; > - membarrier(MEMBARRIER_CMD_SHARED, 0); > + membarrier(MEMBARRIER_CMD_GLOBAL, 0); > *read_a = a; > } I have applied the above patch, and done quite a bit of tweaking, and pushed the results to the git repo. I would be grateful if you would read the entire manual page as it currently stands, to see if anything needs improving. I isolated some of the more significant changes into a simple patch, shown below, and especially I'd like your confirmation that all of those changes are okay. Cheers, Michael diff --git a/man2/membarrier.2 b/man2/membarrier.2 index b3a94f95f..81d573dd5 100644 --- a/man2/membarrier.2 +++ b/man2/membarrier.2 @@ -92,16 +92,18 @@ All threads on the system are targeted by this command. Execute a memory barrier on all running threads of all processes that previously registered with .BR MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED . -Upon return from the system call, the calling thread is ensured that all +Upon return from the system call, the calling thread has a guarantee that all running threads have passed through a state where all memory accesses to user-space addresses match program order between entry to and return from the system call (non-running threads are de facto in such a state). -This covers only threads from processes which registered with +This guarantee is provided only for the threads of processes that +previously registered with .BR MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED . Given that registration is about the intent to receive the barriers, it is valid to invoke .BR MEMBARRIER_CMD_GLOBAL_EXPEDITED -from a non-registered process. +from a process that has not employed +.BR MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED . .IP The "expedited" commands complete faster than the non-expedited ones; they never block, but have the downside of causing extra overhead. @@ -113,17 +115,18 @@ memory barriers. .TP .BR MEMBARRIER_CMD_PRIVATE_EXPEDITED " (since Linux 4.14)" Execute a memory barrier on each running thread belonging to the same -process as the current thread. -Upon return from system call, the calling -thread is assured that all its running threads siblings have passed +process as the calling thread. +Upon return from the system call, the calling +thread has a guarantee that all its running thread siblings have passed through a state where all memory accesses to user-space addresses match program order between entry to and return from the system call (non-running threads are de facto in such a state). -This covers only threads from the same process as the calling thread. +This guarantee is provided only for threads in +the same process as the calling thread. .IP The "expedited" commands complete faster than the non-expedited ones; they never block, but have the downside of causing extra overhead. -A process needs to register its intent to use the private +A process must register its intent to use the private expedited command prior to using it. .TP .BR MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED " (since Linux 4.14)" @@ -133,12 +136,13 @@ Register the process's intent to use .BR MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE " (since Linux 4.16)" In addition to providing the memory ordering guarantees described in .BR MEMBARRIER_CMD_PRIVATE_EXPEDITED , -ensure the calling thread, upon return from system call, that all its -running threads siblings have executed a core serializing instruction. -This only covers threads from the same process as the calling thread. +upon return from system call the calling thread has a guarantee that all its +running thread siblings have executed a core serializing instruction. +This guarantee is provided only for threads in +the same process as the calling thread. The "expedited" commands complete faster than the non-expedited ones, they never block, but have the downside of causing extra overhead. -A process needs to register its intent to use the private expedited sync +A process must register its intent to use the private expedited sync core command prior to using it. .TP .BR MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE " (since Linux 4.16)" -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/