[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] schedule() vs softirqs



On Fri, 2006-12-15 at 21:39 +0000, Keir Fraser wrote:
> On 15/12/06 20:41, "Hollis Blanchard" <hollisb@xxxxxxxxxx> wrote:
> 
> > It's an issue with any architecture with a large number of registers
> > which aren't automatically saved by hardware (and a C ABI that makes
> > some of them non-volatile).
> >
> > x86 has a small number of registers. ia64 automatically saves them (from
> > what I understand). So of the currently-supported architectures, yes,
> > that leaves PowerPC.
> 
> I see. It sounds like returning from context_switch() is perhaps the right
> thing for powerpc. That would be easier if you have per-cpu stacks (like
> ia64).

Yup, we have per-cpu stacks.

> If not there are issues in saving register state later (and hence
> delaying your call to context_saved()) as there are calls to do_softirq()
> outside your asm code (well, not many, but there is one in domain.c for
> example) where you won't end up executing your do_softirq() wrapper. In
> general we'd like to reserve the right to include voluntary yield points,
> and that won't mix well with lazy register saves and per-physical-cpu
> stacks.

Oh, we have per-physical-cpu stacks. We can do that because there's no
such thing as a "hypervisor thread" which could block in hypervisor
space and need to be restored later.

Are you saying in the future you want to have hypervisor threads, and so
we'll need per-VIRTUAL-cpu stacks?

-- 
Hollis Blanchard
IBM Linux Technology Center


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.