Re: [PULL}: latest tip/cpus4096 changes

[Ingo Molnar]

* Mike Travis <travis@xxxxxxx> wrote:

> Ingo Molnar wrote:
> > * Mike Travis <travis@xxxxxxx> wrote:
> > 
> >> commit b758cdbee5da0b8fb7e34a68651e6ccc5310b48a
> >> Author: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
> >> Date:   Thu Jan 15 16:29:16 2009 -0800
> >>
> >>     work_on_cpu: Use our own workqueue.
> >>     
> >>     Impact: remove potential circular lock dependency with generic kevent workqueue
> >>     
> >>     Annoyingly, some places we want to use work_on_cpu are already in
> >>     workqueues.  As per Ingo's suggestion, we create a different workqueue
> >>     for work_on_cpu.
> > 
> > btw., that's a nice fix - were you able to reproduce any of the lockdep 
> > asserts that i got in testing, and did those go away with this patch?
> > 
> > If yes then that's nice and makes work_on_cpu() a lot more usable IMO.
> > 
> > If not then that should generally be declared in the pull request: 
> > "beware, different approach than before but might still trigger lockdep 
> > warnings"
> > 
> > 	Ingo
> 
> Hi,
> 
> I've been trying all sorts of overlapping testing and I've not gotten the
> lockdep warnings any more.  (I do occasionally get that debug object warning
> that I mentioned to Thomas, though that comes and goes irregardless of any
> patches.) [...]

That hpet warning is fixed in tip/timers/urgent [which you wont have if 
you try pure tip/cpus4096].

> [...]  The two fixes that Rusty did (lose the get_online_cpus() and use 
> a separate work queue) seems to have relieved work_on_cpu of it's 
> primary problems, and I've not found any new ones to replace them yet.  
> ;-)
> 
> So I'll "un-push" the entire patchset, and then re-push the x86 only 
> ones, and send the others to their respective maintainers after fixing 
> the problems you mentioned.  (Posting patches to the list was way more 
> fun, and less "committable". ;-)

Sounds good.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/