[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |