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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C35AC433E3 for ; Thu, 16 Jul 2020 15:38:11 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 88B3C2076A for ; Thu, 16 Jul 2020 15:38:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="RgaNfAf/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 88B3C2076A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=efficios.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4B6z0v3wltzDqpM for ; Fri, 17 Jul 2020 01:38:07 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=efficios.com (client-ip=167.114.26.124; helo=mail.efficios.com; envelope-from=compudj@efficios.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=efficios.com header.i=@efficios.com header.a=rsa-sha256 header.s=default header.b=RgaNfAf/; dkim-atps=neutral Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4B6yxF346WzDr58 for ; Fri, 17 Jul 2020 01:34:56 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id C021D295A82; Thu, 16 Jul 2020 11:34:52 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id PgTosnGDK1sK; Thu, 16 Jul 2020 11:34:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 5B51329547E; Thu, 16 Jul 2020 11:34:52 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 5B51329547E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1594913692; bh=L9rT0fzuMGMghk/dEAcEzzkVjyKyZYNObrqiQ0DoanQ=; h=Date:From:To:Message-ID:MIME-Version; b=RgaNfAf/qoYxhHgbRYFkX7WlrrMStDTGaEU8qr/CVA7cq3dKzJPZp1ls9bOuEFOay 713X1tULNXG0XScInlJLS3gVB5DhgcTf/33UG8lAhqwz0cW80lP3OGch5BZRRscWkQ oJjBBhbUW7lZr7hF1UJsCnzhyEtuchi0saqFa97K+NQyihrBZk0dYi1+Gh+v+qprR7 1hPRkBcgiJIgBDsNsL6YTPt6YAuhZ84BiMgu/j2Hr9a0wNhfKNs6NqmtFu3x/Tbw3S MtlD4wlJ9l3TRACzBEGOWf8J7rHyrPo25GYaeAOdDgFhrDNnIn9o3RzBU4ewFK68X3 NgoxFHyBSun8Q== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DMMJqRBwC3nh; Thu, 16 Jul 2020 11:34:52 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id 4B494295833; Thu, 16 Jul 2020 11:34:52 -0400 (EDT) Date: Thu, 16 Jul 2020 11:34:52 -0400 (EDT) From: Mathieu Desnoyers To: Peter Zijlstra Message-ID: <47821133.15875.1594913692220.JavaMail.zimbra@efficios.com> In-Reply-To: <20200716110038.GA119549@hirez.programming.kicks-ass.net> References: <1594868476.6k5kvx8684.astroid@bobo.none> <20200716085032.GO10769@hirez.programming.kicks-ass.net> <1594892300.mxnq3b9a77.astroid@bobo.none> <20200716110038.GA119549@hirez.programming.kicks-ass.net> Subject: Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_3955 (ZimbraWebClient - FF78 (Linux)/8.8.15_GA_3953) Thread-Topic: x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode Thread-Index: iW27IjJDBx/ElQOPTNbM0E0vDOu3JA== X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch , Arnd Bergmann , x86 , linux-kernel , Nicholas Piggin , Andy Lutomirski , linux-mm , Andy Lutomirski , linuxppc-dev Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" ----- On Jul 16, 2020, at 7:00 AM, Peter Zijlstra peterz@infradead.org wrot= e: > On Thu, Jul 16, 2020 at 08:03:36PM +1000, Nicholas Piggin wrote: >> Excerpts from Peter Zijlstra's message of July 16, 2020 6:50 pm: >> > On Wed, Jul 15, 2020 at 10:18:20PM -0700, Andy Lutomirski wrote: >> >> > On Jul 15, 2020, at 9:15 PM, Nicholas Piggin wr= ote: >=20 >> >> But I=E2=80=99m wondering if all this deferred sync stuff is wrong. I= n the >> >> brave new world of io_uring and such, perhaps kernel access matter >> >> too. Heck, even: >> >=20 >> > IIRC the membarrier SYNC_CORE use-case is about user-space >> > self-modifying code. >> >=20 >> > Userspace re-uses a text address and needs to SYNC_CORE before it can = be >> > sure the old text is forgotten. Nothing the kernel does matters there. >> >=20 >> > I suppose the manpage could be more clear there. >>=20 >> True, but memory ordering of kernel stores from kernel threads for >> regular mem barrier is the concern here. >>=20 >> Does io_uring update completion queue from kernel thread or interrupt, >> for example? If it does, then membarrier will not order such stores >> with user memory accesses. >=20 > So we're talking about regular membarrier() then? Not the SYNC_CORE > variant per-se. >=20 > Even there, I'll argue we don't care, but perhaps Mathieu has a > different opinion. I agree with Peter that we don't care about accesses to user-space memory performed concurrently with membarrier. What we'd care about in terms of accesses to user-space memory from the kernel is something that would be clearly ordered as happening before or after the membarrier call, for instance a read(2) followed by membarrier(2) after the read returns, or a read(2) issued after return from membarrier(2). The other scenario we'd care about is with the compiler barrier paired with membarrier: e.g. read(2) returns, compiler barrier, followed by a store. Or load, compiler barrier, followed by write(2). All those scenarios imply before/after ordering wrt either membarrier or the compiler barrier. I notice that io_uring has a "completion" queue. Let's try to come up with realistic usage scenarios. So the dependency chain would be provided by e.g.: * Infrequent read / Frequent write, communicating read completion through v= ariable X wait for io_uring read request completion -> membarrier -> store X=3D1 with matching load from X (waiting for X=3D=3D1) -> asm volatile (::: "memory") -> submit= io_uring write request or this other scenario: * Frequent read / Infrequent write, communicating read completion through v= ariable X load from X (waiting for X=3D=3D1) -> membarrier -> submit io_uring write r= equest with matching wait for io_uring read request completion -> asm volatile (::: "memory") ->= store X=3D1 Thanks, Mathieu --=20 Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com