Received: by 2002:ac0:a591:0:0:0:0:0 with SMTP id m17-v6csp853176imm; Thu, 5 Jul 2018 10:01:31 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfGm6Az6kKBbifZguBNAkLD5YsBTDQ6qGpIhJqrIWrwUQoThIQdPNC0vWYJXJWCY+Md5x3i X-Received: by 2002:a63:4e5f:: with SMTP id o31-v6mr4585103pgl.256.1530810091377; Thu, 05 Jul 2018 10:01:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530810091; cv=none; d=google.com; s=arc-20160816; b=IIKzDLF8Sou/Opp445fB2W4lCZ4G9L+MP9dhV1bpSuAROdk1H4kpDaF1GEntRnvLdf r2ATHS+JMpquDfruf5GA2o0pCURxK8XisXkdllf9VlveugvmX3gcgYuq71aMqMRJTRfb GHdFPTtj4Lcf7V0MssjI/Gj6S1JbLIDml9M/iSXxifC02YZi814G+xHFJz++SB4uL0vF mO5e/iMkxQrXqNMqQI4mNC1OEllPJ2boYszelukYO99xR70uFK1vf2sKM54eUhmLILnp 04mXXMXC4biyeg9lvM4WbUsaB3k7418ZTFAVetvQMq334J9Zs/scrYL25SD1/0M6T/dK ZcXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=fHa5UHPa3rM+96in40ELBBQlkGqdpyOGBiTCJBm9u9s=; b=zfc/OyqhTCoas2N8m3poyp5FcT9YwnAEkQXnIjhH4OwS/B/NTQqYafCROyYWsLsZX4 H40fyyp1+uL/ykdZ3k/B6BNV3cItKCbVWIpUOCw5QCHgRq5UXmdvGVNBLFe5XqPsj7kL mngW1DJnyz63JuP5DXJ/evgZa5GuvIe+Vkli4+73FNpGnEcsL1oA+k5u8SVEEIFONNk2 zZFqZWKvquZVBGj+7yKHXCWJL8+wptRzVLzIgVuLvor7UXVuGXgp+IwF0+I1SjUmCbXl XLIOKtTDYFir6hvoD3Tgyj4NTj65VZZYDuH2x7gEgxhng94CrIcMbrtVtzq+Dtkl9fof 0pjA== 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 q4-v6si6232268plb.251.2018.07.05.10.01.16; Thu, 05 Jul 2018 10:01:31 -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; 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 S1754510AbeGEQ7s (ORCPT + 99 others); Thu, 5 Jul 2018 12:59:48 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:51188 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754109AbeGEQ7r (ORCPT ); Thu, 5 Jul 2018 12:59:47 -0400 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1fb7bV-0008Bz-IK; Thu, 05 Jul 2018 18:59:37 +0200 Date: Thu, 5 Jul 2018 18:59:37 +0200 From: Sebastian Andrzej Siewior To: Joe Korty Cc: Julia Cartwright , tglx@linutronix.de, rostedt@goodmis.org, linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Zijlstra Subject: Re: [PATCH RT] sched/migrate_disable: fallback to preempt_disable() instead barrier() Message-ID: <20180705165937.5orx3md3krg4akaz@linutronix.de> References: <20180704173519.GA24614@zipoli.concurrent-rt.com> <20180705155034.s6q2lsqc3o7srzwp@linutronix.de> <20180705161807.GA5800@zipoli.concurrent-rt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180705161807.GA5800@zipoli.concurrent-rt.com> User-Agent: NeoMutt/20180512 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-07-05 12:18:07 [-0400], joe.korty@concurrent-rt.com wrote: > Hi Sebastian, Hi Joe, > I just verified that this fix does not work for my mix of > config options (smp && preempt && !rt). Okay. So for !RT+SMP we keep migrate_disable() around and it almost nothing. And it is not referenced anywhere so it does not matter as long as it not used directly. We could turn migrate_disable() into a nop/barrier but then we have three uses which do preempt_disable() -> migrate_disable() (see other thread). For the futex code it should not matter much because at this point preemption is disabled due to the spin_lock() (so we would just extend it past the spin_unlock() or wake_futex_pi() which ends with preempt_enable()). > Regards, > Joe Sebastian