Allow fast (1+us) user notification of device interrupts. This allows
more powerful user I/O applications to be written. The process of porting
to other architectures is straight forward and fully documented. More
information can be found at http://oss.sgi.com/projects/uli/.
Signed-off-by: Michael A Raymond <[email protected]>
--
Michael A. Raymond Office: (651) 683-3434
Core OS Group Real-Time System Software
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
On Wed, Mar 23, 2005 at 08:38:33AM -0800, Michael Raymond wrote:
>
> Allow fast (1+us) user notification of device interrupts. This
> allows
> more powerful user I/O applications to be written. The process of
> porting
> to other architectures is straight forward and fully documented. More
> information can be found at [1]http://oss.sgi.com/projects/uli/.
>
>
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
I did the test you suggested. The turning-on and turning-off appeared
to work but our SN Hub ASIC still sent interrupts to the specific CPU.
I looked at my code again and from your description of Hotplug I do not
see any conflicts.
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