public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: linux-kernel@vger.kernel.org, Mike Travis <travis@sgi.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 3/6] cpumask: truncate task_struct.cpus_allowed for CONFIG_CPUMASK_OFFSTACK
Date: Tue, 24 Nov 2009 00:14:40 +0100	[thread overview]
Message-ID: <20091123231440.GA13221@elte.hu> (raw)
In-Reply-To: <200911240918.40418.rusty@rustcorp.com.au>


* Rusty Russell <rusty@rustcorp.com.au> wrote:

> On Tue, 24 Nov 2009 04:53:07 am Ingo Molnar wrote:
> > 
> > * Rusty Russell <rusty@rustcorp.com.au> wrote:
> > 
> > > Turns cpus_allowed into a bitmap, and truncate it to nr_cpu_ids if
> > > CONFIG_CPUMASK_OFFSTACK is set.
> > > 
> > > I do this rather than the classic [0] dangling array trick, because of
> > > INIT_TASK and references to sizeof(struct task_struct).
> > > 
> > > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> > > ---
> > >  include/linux/init_task.h |    2 +-
> > >  include/linux/sched.h     |    7 +++++--
> > >  kernel/fork.c             |   19 ++++++++++++++++++-
> > >  3 files changed, 24 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/include/linux/init_task.h b/include/linux/init_task.h
> > > --- a/include/linux/init_task.h
> > > +++ b/include/linux/init_task.h
> > > @@ -130,7 +130,7 @@ extern struct cred init_cred;
> > >  	.static_prio	= MAX_PRIO-20,					\
> > >  	.normal_prio	= MAX_PRIO-20,					\
> > >  	.policy		= SCHED_NORMAL,					\
> > > -	.cpus_allowed	= CPU_MASK_ALL,					\
> > > +	.cpus_allowed	= CPU_BITS_ALL,					\
> > >  	.mm		= NULL,						\
> > >  	.active_mm	= &init_mm,					\
> > >  	.se		= {						\
> > > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > > --- a/include/linux/sched.h
> > > +++ b/include/linux/sched.h
> > > @@ -1256,7 +1256,6 @@ struct task_struct {
> > >  #endif
> > >  
> > >  	unsigned int policy;
> > > -	cpumask_t cpus_allowed;
> > >  
> > >  #ifdef CONFIG_TREE_PREEMPT_RCU
> > >  	int rcu_read_lock_nesting;
> > > @@ -1544,10 +1543,14 @@ struct task_struct {
> > >  	unsigned long trace_recursion;
> > >  #endif /* CONFIG_TRACING */
> > >  	unsigned long stack_start;
> > > +
> > > +	/* This has to go at the end: if CONFIG_CPUMASK_OFFSTACK=y, only
> > > +	 * nr_cpu_ids bits will actually be allocated. */
> > > +	DECLARE_BITMAP(cpus_allowed, CONFIG_NR_CPUS);
> > 
> > (nit: please use the comment style you see elsewhere in the file.)
> 
> Sure, my mistake.
> 
> > >  };
> > >  
> > >  /* Future-safe accessor for struct task_struct's cpus_allowed. */
> > > -#define tsk_cpumask(tsk) (&(tsk)->cpus_allowed)
> > > +#define tsk_cpumask(tsk) (to_cpumask((tsk)->cpus_allowed))
> > 
> > Please use tsk_cpus_allowed() throughout - so that people who knew what 
> > p->cpus_allowed did know what this new thing does.
> 
> OK.  I chose this because it's shorter and consistent with other uses
> (esp. mm_cpumask).  It's been in Linus' tree for a while, but noone uses
> it so it's easy to rename.

Thanks!

> > Also, i'm still having second thoughts about it all - could we somehow 
> > avoid all this wrappery of commonly used fields? (My main and pretty 
> > much only worry is that struct field members look so much cleaner than 
> > some wrapper intermediary.)
> 
> I'm not a fan either, but it does avoid a flag-day transition.  And I was
> pleasantly surprised how few places access ->cpus_allowed.
> 
> If we use a cpumask_var_t, we still need to change all the callers
> (since it'll now look like a ptr), but we get a gratuitous ptr deref
> for CONFIG_CPUMASK_OFFSTACK=y.
> 
> INIT_TASK needs some tweaking, but it's not a showstopper AFAICT.
> 
> Want me to create a cpumask_var_t version for comparison?

There's also the problem of cache footprint - we really want to freedom 
to place the masks (which are not off-stack in the regular case) 
anywhere in task struct - and task-struct is huge, so cache placement 
matters.

Is the ptr deref really a big problem for off-stack?

Changing all users isnt a problem as long as it still looks like a clean 
data structure with clean usage. Those end-of-struct tricks we play with 
cpumasks make me really a bit uneasy.

	Ingo

  reply	other threads:[~2009-11-23 23:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-19  9:00 [PATCH 3/6] cpumask: truncate task_struct.cpus_allowed for CONFIG_CPUMASK_OFFSTACK Rusty Russell
2009-11-23 18:23 ` Ingo Molnar
2009-11-23 22:48   ` Rusty Russell
2009-11-23 23:14     ` Ingo Molnar [this message]
2009-11-25 11:33       ` Rusty Russell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091123231440.GA13221@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=torvalds@linux-foundation.org \
    --cc=travis@sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox