Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1331130imm; Tue, 22 May 2018 02:15:53 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpjH6KJ8Dr9WaUw6vMjpu52zzu+UvOSGx0uwmsLeNAOi3E+TIbKSi8v3Nltn2zjpEJ/tbYP X-Received: by 2002:a17:902:52ed:: with SMTP id a100-v6mr24002624pli.131.1526980553053; Tue, 22 May 2018 02:15:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526980553; cv=none; d=google.com; s=arc-20160816; b=Mi7oglL9GSZVp4yMEx07PVaan4gtAdCQ1QLMEimaAVbo8z7EVDpadSGNlquIMrM5mE h/D9tQa7uREkPBklNGDxmOsa7GdDV1IKKumwSsaf/8sA5zqfJ7nFUCzpNrPJWcoUMHmF +ueJ4vmVQJyoDqU7yLo1FF25mO2XRFd+QwtCaJ8s7nNbl7so47ZfL0lUHbacYpduQ2Pk tnBPSZ9ZMQSe4t2Z9iPXGsmeRek+xP3grvnZHsineUbSyFwSVswZRJyV6iw5AOWFv7TB JIHAA//9AFZMoukc+V6mRONzeVX4TRt/VVaCz5zhY0AI8juVqOKteRh0if/GWF/o5/IS OpIA== 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=rNwefkpEjMPWsB9ZYtlMGNI738yiR5D1yHXy4lMJXNI=; b=bM68iAllvIS5ksa+BbZZj24NcqO+9awFvMvj8IqN/oqWBUGhLPxKoHkb8+lo1YwGch 2+9DT4ETIjXQ4A6Oi8TIDQb3AeUedZ1ESjp1QiqshgQMOfcSPI/SCIVQ9ncyyjIXjj55 LnNRe0UDEv3u65e0Ovk+c+CPrZzk5VTibYf6H6vI3AMJqZ0Xk/SAivy8wSTXKiZAeBY/ nPWFWkGh6PVPHPIksIE8L4JowUbw+frarooMiANRu9qw5Tjk/sH4i3qsS73cA3ZGCub7 hioOynM05KYbX78TsPAXyuRRoAP/j0On6DpjS//5bNidU8W/WzFG0K+F9gyTmEOYCEZQ pzzQ== 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 f64-v6si16177404pfd.123.2018.05.22.02.15.38; Tue, 22 May 2018 02:15:53 -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 S1751229AbeEVJOM (ORCPT + 99 others); Tue, 22 May 2018 05:14:12 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:38537 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750707AbeEVJOL (ORCPT ); Tue, 22 May 2018 05:14:11 -0400 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1fL3Mv-0001ps-06; Tue, 22 May 2018 11:14:09 +0200 Date: Tue, 22 May 2018 11:14:08 +0200 From: Sebastian Andrzej Siewior To: Mike Galbraith Cc: Thomas Gleixner , linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH] x86: UV: raw_spinlock conversion Message-ID: <20180522091408.nt4fodr4f5ikk5ow@linutronix.de> References: <20180504111459.24825-1-bigeasy@linutronix.de> <20180504111459.24825-2-bigeasy@linutronix.de> <1525604359.28142.3.camel@gmx.de> <20180507073928.shmtfpqyhgxya53b@linutronix.de> <1526738996.5365.1.camel@gmx.de> <20180522065051.xy42nwvcxz2nekti@linutronix.de> <1526977462.6491.1.camel@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1526977462.6491.1.camel@gmx.de> User-Agent: NeoMutt/20180323 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-05-22 10:24:22 [+0200], Mike Galbraith wrote: > On Tue, 2018-05-22 at 08:50 +0200, Sebastian Andrzej Siewior wrote: > > > > Regarding the preempt_disable() in the original patch in uv_read_rtc(): > > This looks essential for PREEMPT configs. Is it possible to get this > > tested by someone or else get rid of the UV code? It looks broken for > > "uv_get_min_hub_revision_id() != 1". > > I suspect SGI cares not one whit about PREEMPT. so it is broken then. I leave it to the x86 maintainers but on the very least it should depend on !PREEMPT (if not server). > > Why does PREEMPT_RT require migrate_disable() but PREEMPT only is fine > > as-is? This does not look right. > > UV is not ok with a PREEMPT config, it's just that for RT it's dirt > simple to shut it up, whereas for PREEMPT, preempt_disable() across > uv_bau_init() doesn't cut it due to allocations, and whatever else I > would have met before ending the whack-a-mole game. > > If I were in your shoes, I think I'd just stop caring about UV until a > real user appears. AFAIK, I'm the only guy who ever ran RT on UV, and > I only did so because SUSE asked me to look into it.. years ago now. Okay. The problem I have with this patch is that it remains RT only while the problem it addresses is not RT-only and PREEMPT kernels are very much affected. The thing is that *you* are my only UV user :) If you suggest that I should stop caring about UV than I do so. Please post a patch that adds a dependency to UV on PREEMPT so that part of the architecture is documented. > -Mike Sebastian