From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-3935789-1517253636-2-9142948301600308146 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, HEADER_FROM_DIFFERENT_DOMAINS 0.001, ME_NOAUTH 0.01, RCVD_IN_DNSWL_HI -5, T_RP_MATCHES_RCVD -0.01, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.132.180.67', Host='vger.kernel.org', Country='US', FromHeader='com', MailFrom='org', XOriginatingCountry='CA' X-Spam-charsets: plain='utf-8' X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: linux-api-owner@vger.kernel.org ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=arctest; t=1517253636; b=cS88EgMMzcFMg9MTPrsDwKFETD4qorMBTOP3ZqtgGOxXTCu UARYYvEY9mFaLYZ6X7qb5LPlpcr5iqbWJik+hjBAF7smbQREltQN2R0GCBHQRlgf aC3ml538zNCRfWmieQ8u8WTYtfZ1yic9o9KHVMwwauT5ZxzSDnMXvOOf3wEbI3lg UPDCzEfBSGxnkJWbnsgewhrT4Da/6DhvNZ48PaVe/ZnH+kujmSEg7gCpF7tyWLGC J058lAoCs0bvcys4lQ/RJIyjQCBM0soG6vXAyR121zPrtK0PMta64tuzJHzBQAlA Ul0uq1eAnK6sWwjowba/uUteLohVzmt+cO3H0PQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type :content-transfer-encoding:sender:list-id; s=arctest; t= 1517253636; bh=rNIHk+nhKVrP4nWAMbNs8qc8binnXqOWnIt976txHDA=; b=X Lp7P0MRjE7Pe5HbMrI5V8A9y/c1Q5OmCA8XUYfN9w4Pyd725LE/nX2bSZLJmynuq fMy/xtRSDkTzMduPiBI3e8nIvNQ7+hr79jXnajWSDaPWb26mHmxgHlIRvL1u8PUS pPSBiOnP4H3mJTiSecPF+AGhXwys2GS1i8Vt49I38ZQNSVC18tn7ubIr0a72yMH2 IvTzWIVx3Ii3gPREHxNdmsIs5OI3atWbQl/jkNM0xccAODlaMlEjcpNvu8NveFHN 7KklrTeiAxvEQmtYFOM1SUXN2W3lmpmTFN9jBlFgcUNV8ur3c9hphChREXZpURNL fREL8QxU5UVVjEpxRNffg== ARC-Authentication-Results: i=1; mx5.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=efficios.com; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=linux-api-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=efficios.com header.result=pass header_is_org_domain=yes Authentication-Results: mx5.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=efficios.com; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=linux-api-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=efficios.com header.result=pass header_is_org_domain=yes Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751574AbeA2TU1 (ORCPT ); Mon, 29 Jan 2018 14:20:27 -0500 Received: from mail.efficios.com ([167.114.142.141]:52237 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751556AbeA2TUZ (ORCPT ); Mon, 29 Jan 2018 14:20:25 -0500 Date: Mon, 29 Jan 2018 19:20:52 +0000 (UTC) From: Mathieu Desnoyers To: Peter Zijlstra Cc: Ingo Molnar , Thomas Gleixner , linux-kernel , linux-api , 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, ARM Linux" , Greg Hackmann , Will Deacon , David Sehr , Linus Torvalds , x86 , linux-arch Message-ID: <579395772.11661.1517253652787.JavaMail.zimbra@efficios.com> In-Reply-To: <20180129190923.GP2249@hirez.programming.kicks-ass.net> References: <20180123155733.3404-1-mathieu.desnoyers@efficios.com> <20180123155733.3404-9-mathieu.desnoyers@efficios.com> <20180129180414.GO2249@hirez.programming.kicks-ass.net> <20180129181529.GG2295@hirez.programming.kicks-ass.net> <485936677.11601.1517250965043.JavaMail.zimbra@efficios.com> <20180129190923.GP2249@hirez.programming.kicks-ass.net> Subject: Re: [PATCH 08/11] membarrier: Provide core serializing command (v2) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.142.141] X-Mailer: Zimbra 8.7.11_GA_1854 (ZimbraWebClient - FF52 (Linux)/8.7.11_GA_1854) Thread-Topic: membarrier: Provide core serializing command (v2) Thread-Index: fw7V+ABDYwP7ogH8iK6WYDxgaf5lww== Sender: linux-api-owner@vger.kernel.org X-Mailing-List: linux-api@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: ----- On Jan 29, 2018, at 2:09 PM, Peter Zijlstra peterz@infradead.org wrote: > On Mon, Jan 29, 2018 at 06:36:05PM +0000, Mathieu Desnoyers wrote: >> ----- On Jan 29, 2018, at 1:15 PM, Peter Zijlstra peterz@infradead.org wrote: > >> > Aaah, its the case where we do not pass through switch_mm(), the partial >> > comment got to me. I only realized after reading the next patch. >> >> Indeed, if we read the entire comment, it's made clear that this case is for >> when switch_mm is not invoked, where the current mm is changed without going >> through switch_mm(), when scheduling between uthread->kthread->uthread for >> instance. >> >> /* >> * When transitioning from a kernel thread to a userspace >> * thread, mmdrop()'s implicit full barrier is required by the >> * membarrier system call, because the current active_mm can >> * become the current mm without going through switch_mm(). >> * membarrier also requires a core serializing instruction >> * before going back to user-space after storing to rq->curr. >> */ >> >> Is there something I should improve in the wording of this added >> sentence to make it clearer ? > > Can be improved I think, its got two unqualified "membarrier"s in and > its a bit mixed up. I'm having a major case of the mondays (brain just > won't start today), but maybe something like: > > When we switched through a kernel thread, the loop in > membarrier_{private,global}_expedited() can have observed that > kernel thread and not issued an IPI. We will also not pass > through switch_mm(). Membarrier requires a barrier after writing > rq->curr and returning to userspace, so provide them here: > > - a full memory barrier for {PRIVATE,GLOBAL}_EXPEDITED > - a sync_core for SYNC_CORE Editing to remove use of "we" and clarify, which ends up as: /* * When switching through a kernel thread, the loop in * membarrier_{private,global}_expedited() may have observed that * kernel thread and not issued an IPI. It is therefore possible to * schedule between user->kernel->user threads without passing though * switch_mm(). Membarrier requires a barrier after storing to * rq->curr, before returning to userspace, so provide them here: * * - a full memory barrier for {PRIVATE,GLOBAL}_EXPEDITED, implicitly * provided by mmdrop(), * - a sync_core for SYNC_CORE. */ > > Also I think changing the changlog to state where we need core-sync > would be good. Currently the x86 patch does that, but not this one, > while this introduces the feature. Planning to add this: Architectures selecting this feature need to either document that they issue core serializing instructions when returning to user-space, or implement their architecture-specific sync_core_before_usermode(). Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com