[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080908183852.GA3713@elte.hu>
Date: Mon, 8 Sep 2008 20:38:52 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Mike Travis <travis@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
davej@...emonkey.org.uk, David Miller <davem@...emloft.net>,
Eric Dumazet <dada1@...mosbay.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Jack Steiner <steiner@....com>,
Jeremy Fitzhardinge <jeremy@...p.org>,
Jes Sorensen <jes@....com>, "H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC 07/13] sched: Reduce stack size requirements in
kernel/sched.c
* Peter Zijlstra <peterz@...radead.org> wrote:
> > > NAK
> >
> > Yeah, I really agree as well. But I wanted to start playing with
> > using cpumask_t pointers in some fairly straight forward manner.
> > Linus's and Ingo's suggestion to just bite the bullet and redefine
> > the cpumask_t would force a lot of changes to be made, but perhaps
> > that's really the way to go.
>
> I much prefer that approach!
seconded. Mike, since none of this is v2.6.27 material, lets do it right
with a v2.6.28 target. You know all the cpumask_t using code sites
inside out already, so the know-how is all available already :-) Please
make it finegrained series of patches so that we can resolve conflicts
with other trees more easily.
perhaps propose the new cpumask_t API early (in this thread?), so that
people can comment on it before NAKs come flying against a full patchset
;-)
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists