From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755997AbdKNRRZ (ORCPT ); Tue, 14 Nov 2017 12:17:25 -0500 Received: from mail-wr0-f196.google.com ([209.85.128.196]:52658 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752092AbdKNRRR (ORCPT ); Tue, 14 Nov 2017 12:17:17 -0500 X-Google-Smtp-Source: AGs4zMbKT2a1pc0U5xeJcs3nrxv97dn2cAKdGUw/kmibmEnNpet7njkHW0iu4g2KEwIszEUsvWtvTw== Subject: Re: [RFC PATCH 0/2] x86: Fix missing core serialization on migration To: Peter Zijlstra , Andy Lutomirski Cc: Thomas Gleixner , Mathieu Desnoyers , Avi Kivity , Linus Torvalds , linux-kernel , linux-api , "Paul E. McKenney" , Boqun Feng , Andrew Hunter , maged michael , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Dave Watson , Ingo Molnar , "H. Peter Anvin" , Andrea Parri , "Russell King, ARM Linux" , Greg Hackmann , Will Deacon , David Sehr , x86 References: <20171110211249.10742-1-mathieu.desnoyers@efficios.com> <885227610.13045.1510351034488.JavaMail.zimbra@efficios.com> <617343212.13932.1510592207202.JavaMail.zimbra@efficios.com> <4d47fbb8-8f99-19d3-a9cf-66841aeffac3@scylladb.com> <4431530.14831.1510672632887.JavaMail.zimbra@efficios.com> <20171114160541.GC3165@worktop.lehotels.local> <20171114163159.GD3165@worktop.lehotels.local> From: Daniel Bristot de Oliveira Message-ID: <6f9f57fa-8057-cdbe-231b-20920b3b3670@redhat.com> Date: Tue, 14 Nov 2017 18:17:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171114163159.GD3165@worktop.lehotels.local> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/14/2017 05:31 PM, Peter Zijlstra wrote: > On Tue, Nov 14, 2017 at 08:16:09AM -0800, Andy Lutomirski wrote: >> What guarantees that there's an IPI? Do we never do a syscall, get >> migrated during syscall processing (due to cond_resched(), for >> example), and land on another CPU that just happened to already be >> scheduling? > > Possible, the other CPU could've pulled the task because it went idle. > No IPIs involved in that scenario. > > And if it was running a different thread of the same process prior to > that, we'll also not do switch_mm(). > > So yes, it is possible to construct a migration scenario without core > serializing instructions (of the CPUID/MOV-CR kind, not the LOCK prefix > kind). > > Note that that still requires a multi-threaded process. > > There is another scenario; where the NOHZ load-balancer moves the task; > such that the NOHZ load balancing CPU is a 3rd CPU. In that case there > is an interrupt (to affect the load-balancing) but it will not land on > the CPU that's going to run the task. > > This could happen for a single threaded task; since I suppose the NOHZ > idle CPU that's going to be the victim could have ran our task last and > still lazily have the mm. > > Very tricky to make work, not to mention that I suspect actually going > idle will kill a whole bunch of state real quick. > IIRC, if the dest cpu is idle and the system is with idle=poll, no IPI is fired as well, but that is not a very common case. -- Daniel