On Tue, Jan 25, 2011 at 10:10:14AM +0100, Martin Husemann wrote:
> On Mon, Jan 24, 2011 at 03:27:58PM +, Mindaugas Rasiukevicius wrote:
> > While looking at the bugs on still work-in-progress mips64 FPU code on
> > Matt's branch, it occurred to me that we could abstract SMP handling
> > complex
Andrew Doran wrote:
> >
> > http://www.netbsd.org/~rmind/subr_pcu.c
> > http://www.netbsd.org/~rmind/pcu.h
> > http://www.netbsd.org/~rmind/pcu.diff
>
> I have three problems with this:
>
> - It uses our xcall interface which provides a mailbox to pass messages
> between CPUs. The intent se
On Mon, Jan 24, 2011 at 03:27:58PM +, Mindaugas Rasiukevicius wrote:
> Hello,
>
> While looking at the bugs on still work-in-progress mips64 FPU code on
> Matt's branch, it occurred to me that we could abstract SMP handling
> complexity into MI interface. Basically, all architectures are usin
Martin Husemann wrote:
>
> I can't make up my mind if this is a complication or proper abstraction.
>
> Assuming it is only used for lazy FPU saving and an arch does not have
> other PCU needs, it overall does not save a lot of work. <...>
Apart from fixing the bugs (which I have found even on
On Mon, Jan 24, 2011 at 03:27:58PM +, Mindaugas Rasiukevicius wrote:
> While looking at the bugs on still work-in-progress mips64 FPU code on
> Matt's branch, it occurred to me that we could abstract SMP handling
> complexity into MI interface. Basically, all architectures are using
> similar
Hello,
While looking at the bugs on still work-in-progress mips64 FPU code on
Matt's branch, it occurred to me that we could abstract SMP handling
complexity into MI interface. Basically, all architectures are using
similar logic for FPU handling on SMP, but each have own variations,
confusions,
