On Fri, Oct 11, 2013 at 09:26:27AM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > > So, I think this code lives within kernel/params.c. Might be fixable?
> >
> > But of course! I was just trying to be lazy. ;-)
> >
> > I could imagine adding a filename field to struct kernel_pa
* Paul E. McKenney wrote:
> > So, I think this code lives within kernel/params.c. Might be fixable?
>
> But of course! I was just trying to be lazy. ;-)
>
> I could imagine adding a filename field to struct kernel_param that was
> initialized with __FILE__, then making something like parameq
On Thu, Oct 10, 2013 at 07:39:37PM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > On Thu, Oct 10, 2013 at 10:05:01AM +0200, Ingo Molnar wrote:
> > >
> > > * Paul E. McKenney wrote:
> > >
> > > > And it now builds, boots, and passes short rcutorture tests, updated
> > > > patch
* Paul E. McKenney wrote:
> On Thu, Oct 10, 2013 at 10:05:01AM +0200, Ingo Molnar wrote:
> >
> > * Paul E. McKenney wrote:
> >
> > > And it now builds, boots, and passes short rcutorture tests, updated
> > > patch below.
> > >
> > > One side-effect is the boot parameters, namely that what u
On Thu, Oct 10, 2013 at 10:05:01AM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > And it now builds, boots, and passes short rcutorture tests, updated
> > patch below.
> >
> > One side-effect is the boot parameters, namely that what used to be
> > rcutree.blimit=10 is now simpl
* Paul E. McKenney wrote:
> And it now builds, boots, and passes short rcutorture tests, updated
> patch below.
>
> One side-effect is the boot parameters, namely that what used to be
> rcutree.blimit=10 is now simply tree.blimit=10. Not a problem for me, I
> just made my test scripts probe
On Wed, Oct 09, 2013 at 07:21:23AM -0700, Paul E. McKenney wrote:
> On Wed, Oct 09, 2013 at 08:08:06AM +0200, Ingo Molnar wrote:
[ . . . ]
> > > Now if it actually still builds, boots, and runs... ;-)
> >
> > Booting is overrated! ;-)
>
> Well, some work is needed on this front, but will get t
On Wed, Oct 09, 2013 at 08:08:06AM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > On Tue, Oct 08, 2013 at 08:28:43PM -0700, Paul E. McKenney wrote:
> > > On Tue, Oct 08, 2013 at 01:40:56PM -0700, Paul E. McKenney wrote:
> > > > On Tue, Oct 08, 2013 at 09:47:18PM +0200, Ingo Molnar
* Paul E. McKenney wrote:
> On Tue, Oct 08, 2013 at 08:28:43PM -0700, Paul E. McKenney wrote:
> > On Tue, Oct 08, 2013 at 01:40:56PM -0700, Paul E. McKenney wrote:
> > > On Tue, Oct 08, 2013 at 09:47:18PM +0200, Ingo Molnar wrote:
>
> [ . . . ]
>
> > > > > Should I be thinking about making a k
On Tue, Oct 08, 2013 at 08:28:43PM -0700, Paul E. McKenney wrote:
> On Tue, Oct 08, 2013 at 01:40:56PM -0700, Paul E. McKenney wrote:
> > On Tue, Oct 08, 2013 at 09:47:18PM +0200, Ingo Molnar wrote:
[ . . . ]
> > > > Should I be thinking about making a kernel/rcu?
> > >
> > > I wanted to raise i
On Tue, Oct 08, 2013 at 01:40:56PM -0700, Paul E. McKenney wrote:
> On Tue, Oct 08, 2013 at 09:47:18PM +0200, Ingo Molnar wrote:
> >
> > * Paul E. McKenney wrote:
> >
> > > On Tue, Oct 08, 2013 at 12:23:31PM +0200, Ingo Molnar wrote:
> > > >
> > > > * Peter Zijlstra wrote:
> > > >
> > > > > O
On Tue, Oct 08, 2013 at 11:06:07PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 08, 2013 at 01:41:29PM -0700, Paul E. McKenney wrote:
> > On Tue, Oct 08, 2013 at 10:01:55PM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 08, 2013 at 09:47:18PM +0200, Ingo Molnar wrote:
> > > > To me it would sure look
On Tue, Oct 08, 2013 at 01:41:29PM -0700, Paul E. McKenney wrote:
> On Tue, Oct 08, 2013 at 10:01:55PM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 08, 2013 at 09:47:18PM +0200, Ingo Molnar wrote:
> > > To me it would sure look nice to have kernel/rcu/tree.c,
> > > kernel/rcu/tiny.c, kernel/rcu/co
On Tue, Oct 08, 2013 at 09:47:18PM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > On Tue, Oct 08, 2013 at 12:23:31PM +0200, Ingo Molnar wrote:
> > >
> > > * Peter Zijlstra wrote:
> > >
> > > > On Sat, Oct 05, 2013 at 10:04:16AM +0200, Ingo Molnar wrote:
> > > > >
> > > > > * P
On Tue, Oct 08, 2013 at 10:01:55PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 08, 2013 at 09:47:18PM +0200, Ingo Molnar wrote:
> > To me it would sure look nice to have kernel/rcu/tree.c,
> > kernel/rcu/tiny.c, kernel/rcu/core.c, etc.
> >
> > [ ... and we would certainly also break new ground by
On Tue, Oct 08, 2013 at 09:47:18PM +0200, Ingo Molnar wrote:
> To me it would sure look nice to have kernel/rcu/tree.c,
> kernel/rcu/tiny.c, kernel/rcu/core.c, etc.
>
> [ ... and we would certainly also break new ground by introducing a
> "torture.c" file, for the first time in Linux kernel his
* Paul E. McKenney wrote:
> On Tue, Oct 08, 2013 at 12:23:31PM +0200, Ingo Molnar wrote:
> >
> > * Peter Zijlstra wrote:
> >
> > > On Sat, Oct 05, 2013 at 10:04:16AM +0200, Ingo Molnar wrote:
> > > >
> > > > * Peter Zijlstra wrote:
> > > >
> > > > > On Fri, Oct 04, 2013 at 10:44:05PM +0200
On Tue, Oct 08, 2013 at 12:23:31PM +0200, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > On Sat, Oct 05, 2013 at 10:04:16AM +0200, Ingo Molnar wrote:
> > >
> > > * Peter Zijlstra wrote:
> > >
> > > > On Fri, Oct 04, 2013 at 10:44:05PM +0200, Peter Zijlstra wrote:
> > > > >
> > > > > sl
* Peter Zijlstra wrote:
> On Sat, Oct 05, 2013 at 10:04:16AM +0200, Ingo Molnar wrote:
> >
> > * Peter Zijlstra wrote:
> >
> > > On Fri, Oct 04, 2013 at 10:44:05PM +0200, Peter Zijlstra wrote:
> > > >
> > > > slightly related; do we want to do something like the following two
> > > > patches
On Sat, Oct 05, 2013 at 10:04:16AM +0200, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > On Fri, Oct 04, 2013 at 10:44:05PM +0200, Peter Zijlstra wrote:
> > >
> > > slightly related; do we want to do something like the following two
> > > patches?
> >
> > and
>
> Yeah, both look good to
* Peter Zijlstra wrote:
> On Fri, Oct 04, 2013 at 10:44:05PM +0200, Peter Zijlstra wrote:
> >
> > slightly related; do we want to do something like the following two
> > patches?
>
> and
Yeah, both look good to me - but I'd move them into
kernel/sched/completion.c and kernel/sched/wait.c if
On Fri, Oct 04, 2013 at 10:44:05PM +0200, Peter Zijlstra wrote:
>
> slightly related; do we want to do something like the following two
> patches?
and
---
Subject: sched: Move completion code
From: Peter Zijlstra
Date: Fri Oct 4 22:06:53 CEST 2013
Completions already have their own header fil
slightly related; do we want to do something like the following two
patches?
---
Subject: sched: Move wait code
From: Peter Zijlstra
Date: Fri Oct 4 17:24:35 CEST 2013
For some reason only the wait part of the wait api lives in
kernel/wait.c and the wake part still lives in kernel/sched/core.c;
While poking at the cpu hotplug implementation I had a desire to use
wait_event() with schedule_preempt_disabled() and found the ridiculous
amount of duplication in linux/wait.h.
These patches cure all the bloat and inconsistencies of these macros
that me and others noticed, while also making it '
24 matches
Mail list logo
