From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934453AbdDFKfg (ORCPT ); Thu, 6 Apr 2017 06:35:36 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:49750 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932662AbdDFKf2 (ORCPT ); Thu, 6 Apr 2017 06:35:28 -0400 Date: Thu, 6 Apr 2017 12:35:16 +0200 From: Peter Zijlstra To: Sebastian Andrzej Siewior Cc: linux-kernel@vger.kernel.org, Thomas Gleixner , Mike Galbraith , Ingo Molnar , "Rafael J . Wysocki" Subject: Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU mask Message-ID: <20170406103516.i3jyjcmee65r3wwj@hirez.programming.kicks-ass.net> References: <20170404184202.20376-1-bigeasy@linutronix.de> <20170406093224.q3tunb6gdx5a6flr@hirez.programming.kicks-ass.net> <20170406094626.a42cq66ezgq4lohh@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170406094626.a42cq66ezgq4lohh@linutronix.de> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 06, 2017 at 11:46:33AM +0200, Sebastian Andrzej Siewior wrote: > On 2017-04-06 11:32:24 [+0200], Peter Zijlstra wrote: > > On Tue, Apr 04, 2017 at 08:42:02PM +0200, Sebastian Andrzej Siewior wrote: > > > While converting the existing users I tried to stick with the rules > > > above however… well mostly CPUFREQ tries to temporary switch the CPU > > > mask to do something on a certain CPU and then switches the mask back it > > > its original value. > > > > > > There's a bunch of that through ancient and rotten parts of the kernel. > > All those sites are broken. > > > > Nothing stops userspace from setting a different affinity right after > > the kernel does for those threads. > > Good. So you are saying I should convert them to something like > queue_work_on()? Not sure; iirc there were a few variants. Some can indeed simply do queue_work_on() and possibly wait for completion. some should maybe be a per-cpu kthread, others will be more 'interesting'. IIRC MIPS has a case where only 1 in N cores has an FPU. And once a task uses FPU, it gets affined to the core that has one or something like that. Of course, nothing then stops someone else breaking that affinity. But I suspect it will simply fault on the next FPU instruction and 'reset' the mask or something. I've no clue and no real desire to know.