From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751886AbdBIHJ5 (ORCPT ); Thu, 9 Feb 2017 02:09:57 -0500 Received: from mail-wm0-f44.google.com ([74.125.82.44]:34604 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751670AbdBIHJz (ORCPT ); Thu, 9 Feb 2017 02:09:55 -0500 Date: Thu, 9 Feb 2017 07:45:01 +0100 From: Ingo Molnar To: Peter Zijlstra Cc: Thomas Gleixner , Mike Galbraith , Ingo Molnar , Sebastian Andrzej Siewior , LKML Subject: Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed() Message-ID: <20170209064501.GA27072@gmail.com> References: <1486355037.10462.17.camel@gmx.de> <20170206103156.GA18908@gmail.com> <1486383511.10462.43.camel@gmx.de> <20170206122928.GB9404@gmail.com> <20170206133242.GK6515@twins.programming.kicks-ass.net> <20170206222313.GA6061@gmail.com> <20170208114016.GX6500@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170208114016.GX6500@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Peter Zijlstra wrote: > On Wed, Feb 08, 2017 at 11:20:19AM +0100, Thomas Gleixner wrote: > > On Mon, 6 Feb 2017, Ingo Molnar wrote: > > > * Peter Zijlstra wrote: > > > > > > > > cpumasks are a pain, the above avoids allocating more of them. > > > > Indeed. > > > > > Yeah, so this could then be done by pointerifying ->cpus_allowed - more robust > > > than the wrappery, > > > > You mean: > > > > struct task_struct { > > cpumask_t cpus_allowed; > > cpumask_t *effective_cpus_allowed; > > }; Yeah. I'd name it a bit differently and constify the pointer to get type safety and to make sure the mask is never modified through the pointer: struct task_struct { const cpumask_t *cpus_ptr; cpumask_t cpus_mask; }; ( I'd drop the 'allowed' part, it's obvious enough what task->cpus_mask does, right? ) and upstream would essentially just do: t->cpus_allowed_ptr = &t->cpus_allowed; And -rt, when it wants to pin a task, would do: t->cpus_allowed_ptr = &cpumask_of(task_cpu(p)); The rules are: - Code that 'uses' ->cpus_allowed would use the pointer. - Code that 'modifies' ->cpus_allowed would use the direct mask. The upstream advantages are: - The type separation of modifications from usage. - Removal of wrappery. - Maybe sometime in the future upstream would want to disable migration too ... In fact -rt gains something too: - With this scheme we would AFAICS get slightly more optimal code on -rt. (Because there's no __migration_disabled() branching anymore.) - Plus all new code is automatically -rt ready - no need to maintain the wrappery space. Much less code path forking. So as I see it it's win-win for both upstream and for -rt! > > and make the scheduler use effective_cpus_allowed instead of cpus_allowed? Or > > what do you have in mind? > > That scheme is weird for nr_cpus_allowed. Not to mention that the > pointer to the integer is larger than the integer itself. So in the new scheme I don't think nr_cpus_allowed would have to be wrapped at all: whenever the pointer (or mask) is changed in set_cpus_allowed_common() nr_cpus_allowed is recalculated as well - like today. It should be self-maintaining. Am I missing something? > I really prefer the current wrappers, they're trivial and consistent > with one another. I think it's ugly wrappery and we can do better! ;-) But of course if I cannot suggest a better alternative then it stands. Thanks, Ingo