Once the ULI code has taken over a CPU, it should not be rescheduable
until the ULI completes. The goal is a very fast jump in and out of user
space. Primitives are provided for the waking of another thread / process
if the applications needs to do a lot of work.
If I've left open the possibility of a reschedule, then it was a design
error. As I think about it though everything should still work fine, but
it's purely by accident. :)
If you have test code for hotplug I'd be happy to test it for you.
Thanks,
Michael
On Wed, Mar 23, 2005 at 02:57:39PM -0800, Ashok Raj wrote:
> Hi Michael
>
> have you thought about how this infrastructure would play well with
> existing CPU hotplug code for ia64?
>
> Once you return to user mode via the iret, is it possible that user mode
> thread could get switched due to a pending cpu quiese attempt to remove
> a cpu? (Current cpu removal code would bring the entire system to knees
> by scheduling a high priority thread and looping with intr disabled, until the
> target cpu is removed)
>
> the cpu removal code would also attempt to migrate user process to another cpu,
> retarget interrupts to another existing cpu etc. I havent tested the hotplug
> code on sgi boxes so far. (only tested on some hp boxes by Alex Williamson
> and on tiger4 boxes so far)
>
> Cheers,
> ashok
--
Michael A. Raymond Office: (651) 683-3434
Core OS Group Real-Time System Software
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
