From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754131AbdDFKra (ORCPT ); Thu, 6 Apr 2017 06:47:30 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:36476 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752417AbdDFKrY (ORCPT ); Thu, 6 Apr 2017 06:47:24 -0400 Date: Thu, 6 Apr 2017 12:47:21 +0200 (CEST) From: Thomas Gleixner To: Peter Zijlstra cc: Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, Mike Galbraith , Ingo Molnar , "Rafael J . Wysocki" Subject: Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU mask In-Reply-To: <20170406103516.i3jyjcmee65r3wwj@hirez.programming.kicks-ass.net> Message-ID: References: <20170404184202.20376-1-bigeasy@linutronix.de> <20170406093224.q3tunb6gdx5a6flr@hirez.programming.kicks-ass.net> <20170406094626.a42cq66ezgq4lohh@linutronix.de> <20170406103516.i3jyjcmee65r3wwj@hirez.programming.kicks-ass.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-2004815220-1491475641=:1716" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-2004815220-1491475641=:1716 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Thu, 6 Apr 2017, Peter Zijlstra wrote: > 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. It does nasty games with it's own storage of p->thread.user_cpus_allowed and a fully seperate implementation of sys_sched_set|getaffinity. Plus a magic trap handler which forces the thread to a CPU with FPU when the user_cpus_allowed mask intersects with the cpus_with_fpu_mask... Magic crap, which could all be replaced by a simple function in the scheduler which allows to push a task to a FPU CPU and then disable migration. Thanks, tglx --8323329-2004815220-1491475641=:1716--