Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp1656856imj; Sun, 17 Feb 2019 11:01:19 -0800 (PST) X-Google-Smtp-Source: AHgI3IZ+ruCk/PVKKqTm360yI7prK4X3qTVow1eOthb3fHnylHQMD+DDOMOaGTOwr5Y6xWS4Gl0c X-Received: by 2002:a63:28c1:: with SMTP id o184mr1076221pgo.123.1550430079459; Sun, 17 Feb 2019 11:01:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550430079; cv=none; d=google.com; s=arc-20160816; b=zDODimX2j/K5f2lgQLC/q09WrwXt7RGi7Yj9DENc9QxKyQtjrJKO8BeWTd7alnya51 Vzkl5gyz9HG451oPkd+aUtnTgqPDRTDwTi68M8Meb5fnssYPueN7/CueYmsjMEhSV72i hk8Yyz2jx+8a4Cwynv5AfXw3XjS2JXe7K+3+IiTIPUpRndVCHh5ODuQuFu2Pd6Pd6Dhs EW97SYplL+ThLRNWw4LCMJpPVvRJKp+BevlkgkRJYDrey1t4AxtPuGNmqSnwcMFE53fI fT79Ux4KdLdWk3rhZo9SnZ3ofzyb5yxDJURjxcilKH9UuyPXhlD07D2WK0/+aeKDXp52 0lpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:content-disposition :mime-version:message-id:subject:cc:to:from:date; bh=eFY2IO1X9PeO2N8ZYr3P4UR8v34ABJoTFar4jPBCIbA=; b=F388uJZjJZy8EM3xRJ1LbVSTmoGtqQkHWUScvMMcViaen3H1NnIuAm6u4dNttGiY3Z UxtCw4RS+0qe0fCX6d4O2/FBHYVEWYiy1wEeWYWB+qkTqJ8uNdNeMzj8Pqo+JsNwDuPx 83RvhHjAHroebrpy/gC1PiJ/M+BJ2iODiq0g9RGea2PmZXREn6BCBAi/IQsD5LXCY5TQ +fHL6xqSqNqxzZ7Tp/2y1l6clceBHGG8ougDVEScwzauAT8xdVHP6rU7CIdrThur+FA8 ugf9wHoooikXxmbF2jcXQYjt3TciDGBmJLGj/nbPoNoEyU3U1VWm9Q77r6HvCzTeVNuw JI7A== 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 g12si11491758plp.9.2019.02.17.11.01.02; Sun, 17 Feb 2019 11:01:19 -0800 (PST) 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 S1726141AbfBQTAs (ORCPT + 99 others); Sun, 17 Feb 2019 14:00:48 -0500 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:59892 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725554AbfBQTAr (ORCPT ); Sun, 17 Feb 2019 14:00:47 -0500 X-Greylist: delayed 750 seconds by postgrey-1.27 at vger.kernel.org; Sun, 17 Feb 2019 14:00:47 EST Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1gvRTs-0004Fp-00; Sun, 17 Feb 2019 18:48:00 +0000 Date: Sun, 17 Feb 2019 13:48:00 -0500 From: Rich Felker To: linux-kernel@vger.kernel.org Cc: Mathieu Desnoyers , "Paul E. McKenney" , Peter Zijlstra , Ingo Molnar , Alexander Viro Subject: Regression in SYS_membarrier expedited Message-ID: <20190217184800.GA16118@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org commit a961e40917fb14614d368d8bc9782ca4d6a8cd11 made it so that the MEMBARRIER_CMD_PRIVATE_EXPEDITED command cannot be used without first registering intent to use it. However, registration is an expensive operation since commit 3ccfebedd8cf54e291c809c838d8ad5cc00f5688, which added synchronize_sched() to it; this means it's no longer possible to lazily register intent at first use, and it's unreasonably expensive to preemptively register intent for possibly extremely-short-lived processes that will never use it. (My usage case is in libc (musl), where I can't know if the process will be short- or long-lived; unnecessary and potentially expensive syscalls can't be made preemptively, only lazily at first use.) Can we restore the functionality of MEMBARRIER_CMD_PRIVATE_EXPEDITED to work even without registration? The motivation of requiring registration seems to be: "Registering at this time removes the need to interrupt each and every thread in that process at the first expedited sys_membarrier() system call." but interrupting every thread in the process is exactly what I expect, and is not a problem. What does seem like a big problem is waiting for synchronize_sched() to synchronize with an unboundedly large number of cores (vs only a few threads in the process), especially in the presence of full_nohz, where it seems like latency would be at least a few ms and possibly unbounded. Short of a working SYS_membarrier that doesn't require expensive pre-registration, I'm stuck just implementing it in userspace with signals... Rich