Re: [PATCH] User Level Interrupts
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 - 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/
Re: [PATCH] User Level Interrupts
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 - 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/
Re: [PATCH] User Level Interrupts
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/
[PATCH] User Level Interrupts
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 diff -urN linux-2.6.11/arch/ia64/kernel/asm-offsets.c linux-2.6.11-uli/arch/ia64/kernel/asm-offsets.c --- linux-2.6.11/arch/ia64/kernel/asm-offsets.c 2005-03-10 06:44:14.693503599 -0600 +++ linux-2.6.11-uli/arch/ia64/kernel/asm-offsets.c 2005-03-10 06:45:49.777264508 -0600 @@ -7,6 +7,7 @@ #include #include +#include #include #include @@ -236,4 +237,19 @@ DEFINE(IA64_TIME_SOURCE_MMIO64, TIME_SOURCE_MMIO64); DEFINE(IA64_TIME_SOURCE_MMIO32, TIME_SOURCE_MMIO32); DEFINE(IA64_TIMESPEC_TV_NSEC_OFFSET, offsetof (struct timespec, tv_nsec)); + +#ifdef CONFIG_ULI + BLANK(); + DEFINE(ULI_GP_OFFSET, offsetof(struct uli, uli_gp)); + DEFINE(ULI_SP_OFFSET, offsetof(struct uli, uli_sp)); + DEFINE(ULI_BSPSTORE_OFFSET, offsetof(struct uli, uli_arch0)); + DEFINE(ULI_TP_OFFSET, offsetof(struct uli, uli_arch1)); + DEFINE(ULI_PC_OFFSET, offsetof(struct uli, uli_pc)); + DEFINE(ULI_ARG_OFFSET, offsetof(struct uli, uli_funcarg)); + DEFINE(ULI_TSTAMP_OFFSET, offsetof(struct uli, uli_tstamp)); + DEFINE(ULI_DOUBLE_OFFSET, offsetof(struct uli, uli_double)); + DEFINE(ULI_INTR_SP_OFFSET, offsetof(struct uli, uli_intr_sp)); + DEFINE(ULI_INTR_BSPSTORE_OFFSET, offsetof(struct uli, uli_intr_arch0)); + DEFINE(ULI_SAVED_EPC_OFFSET, offsetof(struct uli, uli_saved_epc)); +#endif /* CONFIG_ULI */ } diff -urN linux-2.6.11/arch/ia64/kernel/entry.S linux-2.6.11-uli/arch/ia64/kernel/entry.S --- linux-2.6.11/arch/ia64/kernel/entry.S 2005-03-02 01:37:50.0 -0600 +++ linux-2.6.11-uli/arch/ia64/kernel/entry.S 2005-03-22 08:41:17.597377762 -0600 @@ -698,6 +698,16 @@ (pUStk)cmp.eq.unc p6,p0=r0,r0 // p6 <- pUStk #endif .work_processed_syscall: +#ifdef CONFIG_ULI + addl r22 = THIS_CPU(uli_cur),r0 // uli_cur + ;; + ld8 r22 = [r22] // load current ULI + ;; +(p6) cmp.eq p6,p0=r0,r22 // If would do work && no ULI, then can still check +(pUStk) cmp.eq.unc p7,p0=r0,r22 // Don't store to on_ustack if there's a ULI +#else /* CONFIG_ULI */ +(pUStk) cmp.eq.unc p7,p0=r0,r0 +#endif /* CONFIG_ULI */ adds r2=PT(LOADRS)+16,r12 adds r3=PT(AR_BSPSTORE)+16,r12 adds r18=TI_FLAGS+IA64_TASK_SIZE,r13 @@ -760,7 +770,7 @@ addl r3=THIS_CPU(ia64_phys_stacked_size_p8),r0 ;; (pUStk)ld4 r3=[r3] // r3 = cpu_data->phys_stacked_size_p8 -(pUStk) st1 [r14]=r17 +(p7) st1 [r14]=r17 mov b6=r18 // I0 restore b6 ;; mov r14=r0 // clear r14 @@ -814,6 +824,14 @@ (pUStk)cmp.eq.unc p6,p0=r0,r0 // p6 <- pUStk #endif .work_processed_kernel: +#ifdef CONFIG_ULI + addl r22 = THIS_CPU(uli_cur),r0 // uli_cur + ;; + ld8 r22 = [r22] // load current ULI + ;; +(p6) cmp.eq p6,p0=r0,r22 // If would do work && no ULI, then can still check + cmp.eq p9,p7=r0,r22 // Set p7 if there's a current ULI +#endif /* CONFIG_ULI */ adds r17=TI_FLAGS+IA64_TASK_SIZE,r13 ;; (p6) ld4 r31=[r17] // load current_thread_info()->flags @@ -842,13 +860,44 @@ ;; ld8 r31=[r2],16 // load ar.ssd ld8.fill r8=[r3],16 +#ifdef CONFIG_ULI +(p7) add r19 = ULI_DOUBLE_OFFSET,r22 /* _uli->uli_double */ +#endif /* CONFIG_ULI */ ;; ld8.fill r9=[r2],16 ld8.fill r10=[r3],PT(R17)-PT(R10) +#ifdef CONFIG_ULI +(p7)add r18 = ULI_TSTAMP_OFFSET,r22 +#endif /* CONFIG_ULI */ ;; ld8.fill r11=[r2],PT(R18)-PT(R11) ld8.fill r17=[r3],16 +(pUStk) cmp.eq.unc p6,p0=r0,r0 /* p6 was false, set to pUStk */ + ;; +#ifdef CONFIG_ULI +/* We need to check if the current ULI has been running too long */ +(p9) br.cond.sptk.many 1f /* No current ULI, skip the check */ + ;; + ld4 r22=[r19] /* *cur_uli->uli_double, # of double intrs */ + ld8 r18=[r18] /* *tstamp */ + cmp.eq p0,p6=r0,r0 /* If there's a current ULI, p6 becomes false */ + ;; + mov r23 = ar.itc /* Get the current time */ + sub r22=r22,r0,1 /* One less nested level above ULI handler */ + ;; + cmp.eq p8,p9=r22,r0 /* Returning into a handler? */ + st4 [r19] = r22 /* store lower # of doubles */ + ;; +(p8) cmp.ge p0,p9=r23,r18 /* Returning into a handler && overrun? */ + ;; +(p9) br.cond.sptk.many 1f /* No overrun, continue exiting */ + alloc r0=ar.pfs,0,0,2,0 /* There's been an overrun, abort the ULI */ ;; +
[PATCH] User Level Interrupts
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 diff -urN linux-2.6.11/arch/ia64/kernel/asm-offsets.c linux-2.6.11-uli/arch/ia64/kernel/asm-offsets.c --- linux-2.6.11/arch/ia64/kernel/asm-offsets.c 2005-03-10 06:44:14.693503599 -0600 +++ linux-2.6.11-uli/arch/ia64/kernel/asm-offsets.c 2005-03-10 06:45:49.777264508 -0600 @@ -7,6 +7,7 @@ #include linux/config.h #include linux/sched.h +#include linux/uli.h #include asm-ia64/processor.h #include asm-ia64/ptrace.h @@ -236,4 +237,19 @@ DEFINE(IA64_TIME_SOURCE_MMIO64, TIME_SOURCE_MMIO64); DEFINE(IA64_TIME_SOURCE_MMIO32, TIME_SOURCE_MMIO32); DEFINE(IA64_TIMESPEC_TV_NSEC_OFFSET, offsetof (struct timespec, tv_nsec)); + +#ifdef CONFIG_ULI + BLANK(); + DEFINE(ULI_GP_OFFSET, offsetof(struct uli, uli_gp)); + DEFINE(ULI_SP_OFFSET, offsetof(struct uli, uli_sp)); + DEFINE(ULI_BSPSTORE_OFFSET, offsetof(struct uli, uli_arch0)); + DEFINE(ULI_TP_OFFSET, offsetof(struct uli, uli_arch1)); + DEFINE(ULI_PC_OFFSET, offsetof(struct uli, uli_pc)); + DEFINE(ULI_ARG_OFFSET, offsetof(struct uli, uli_funcarg)); + DEFINE(ULI_TSTAMP_OFFSET, offsetof(struct uli, uli_tstamp)); + DEFINE(ULI_DOUBLE_OFFSET, offsetof(struct uli, uli_double)); + DEFINE(ULI_INTR_SP_OFFSET, offsetof(struct uli, uli_intr_sp)); + DEFINE(ULI_INTR_BSPSTORE_OFFSET, offsetof(struct uli, uli_intr_arch0)); + DEFINE(ULI_SAVED_EPC_OFFSET, offsetof(struct uli, uli_saved_epc)); +#endif /* CONFIG_ULI */ } diff -urN linux-2.6.11/arch/ia64/kernel/entry.S linux-2.6.11-uli/arch/ia64/kernel/entry.S --- linux-2.6.11/arch/ia64/kernel/entry.S 2005-03-02 01:37:50.0 -0600 +++ linux-2.6.11-uli/arch/ia64/kernel/entry.S 2005-03-22 08:41:17.597377762 -0600 @@ -698,6 +698,16 @@ (pUStk)cmp.eq.unc p6,p0=r0,r0 // p6 - pUStk #endif .work_processed_syscall: +#ifdef CONFIG_ULI + addl r22 = THIS_CPU(uli_cur),r0 // uli_cur + ;; + ld8 r22 = [r22] // load current ULI + ;; +(p6) cmp.eq p6,p0=r0,r22 // If would do work no ULI, then can still check +(pUStk) cmp.eq.unc p7,p0=r0,r22 // Don't store to on_ustack if there's a ULI +#else /* CONFIG_ULI */ +(pUStk) cmp.eq.unc p7,p0=r0,r0 +#endif /* CONFIG_ULI */ adds r2=PT(LOADRS)+16,r12 adds r3=PT(AR_BSPSTORE)+16,r12 adds r18=TI_FLAGS+IA64_TASK_SIZE,r13 @@ -760,7 +770,7 @@ addl r3=THIS_CPU(ia64_phys_stacked_size_p8),r0 ;; (pUStk)ld4 r3=[r3] // r3 = cpu_data-phys_stacked_size_p8 -(pUStk) st1 [r14]=r17 +(p7) st1 [r14]=r17 mov b6=r18 // I0 restore b6 ;; mov r14=r0 // clear r14 @@ -814,6 +824,14 @@ (pUStk)cmp.eq.unc p6,p0=r0,r0 // p6 - pUStk #endif .work_processed_kernel: +#ifdef CONFIG_ULI + addl r22 = THIS_CPU(uli_cur),r0 // uli_cur + ;; + ld8 r22 = [r22] // load current ULI + ;; +(p6) cmp.eq p6,p0=r0,r22 // If would do work no ULI, then can still check + cmp.eq p9,p7=r0,r22 // Set p7 if there's a current ULI +#endif /* CONFIG_ULI */ adds r17=TI_FLAGS+IA64_TASK_SIZE,r13 ;; (p6) ld4 r31=[r17] // load current_thread_info()-flags @@ -842,13 +860,44 @@ ;; ld8 r31=[r2],16 // load ar.ssd ld8.fill r8=[r3],16 +#ifdef CONFIG_ULI +(p7) add r19 = ULI_DOUBLE_OFFSET,r22 /* cur_uli-uli_double */ +#endif /* CONFIG_ULI */ ;; ld8.fill r9=[r2],16 ld8.fill r10=[r3],PT(R17)-PT(R10) +#ifdef CONFIG_ULI +(p7)add r18 = ULI_TSTAMP_OFFSET,r22 +#endif /* CONFIG_ULI */ ;; ld8.fill r11=[r2],PT(R18)-PT(R11) ld8.fill r17=[r3],16 +(pUStk) cmp.eq.unc p6,p0=r0,r0 /* p6 was false, set to pUStk */ + ;; +#ifdef CONFIG_ULI +/* We need to check if the current ULI has been running too long */ +(p9) br.cond.sptk.many 1f /* No current ULI, skip the check */ + ;; + ld4 r22=[r19] /* *cur_uli-uli_double, # of double intrs */ + ld8 r18=[r18] /* *tstamp */ + cmp.eq p0,p6=r0,r0 /* If there's a current ULI, p6 becomes false */ + ;; + mov r23 = ar.itc /* Get the current time */ + sub r22=r22,r0,1 /* One less nested level above ULI handler */ + ;; + cmp.eq p8,p9=r22,r0 /* Returning into a handler? */ + st4 [r19] = r22 /* store lower # of doubles */ + ;; +(p8) cmp.ge p0,p9=r23,r18 /* Returning into a handler overrun? */ + ;; +(p9) br.cond.sptk.many 1f /* No overrun, continue exiting */ + alloc
Re: [PATCH] User Level Interrupts
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/
Re: User mode drivers: part 1, interrupt handling (patch for 2.6.11)
We have some customers doing high performance raw I/O from various PCI & VME cards. They can already mmap() and do DMA from user space to the cards. Allowing them to do interrupt processing in user space allows them to keep everything in one tight package. The ULI web site talks about this a little more. Thanks, Michael On Fri, Mar 11, 2005 at 09:25:14AM -0800, Greg KH wrote: > On Fri, Mar 11, 2005 at 07:50:32AM -0600, Michael Raymond wrote: > > I have many users asking for something like this. > > Why would a "user" care about this? > > Now hardware companies that want to write closed drivers is another > thing :) > > thanks, > > greg k-h -- 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/
Re: User mode drivers: part 1, interrupt handling (patch for 2.6.11)
I have many users asking for something like this. Peter's approach is simple and it appears to solve the problem for many situations. With that in mind though, for a more complicated but higher performing approach please take a look at the User Level Interrupt (ULI) project at http://oss.sgi.com/projects/uli/. It requires some per-arch assembly but with some recent changes we're seeing ~1.5us latency from hardware event to user space function start. I'm hoping to add an IA32 port out soon. Thanks, Michael On Fri, Mar 11, 2005 at 02:36:10PM +1100, Peter Chubb wrote: > > As many of you will be aware, we've been working on infrastructure for > user-mode PCI and other drivers. The first step is to be able to > handle interrupts from user space. Subsequent patches add > infrastructure for setting up DMA for PCI devices. -- 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/
Re: User mode drivers: part 1, interrupt handling (patch for 2.6.11)
I have many users asking for something like this. Peter's approach is simple and it appears to solve the problem for many situations. With that in mind though, for a more complicated but higher performing approach please take a look at the User Level Interrupt (ULI) project at http://oss.sgi.com/projects/uli/. It requires some per-arch assembly but with some recent changes we're seeing ~1.5us latency from hardware event to user space function start. I'm hoping to add an IA32 port out soon. Thanks, Michael On Fri, Mar 11, 2005 at 02:36:10PM +1100, Peter Chubb wrote: As many of you will be aware, we've been working on infrastructure for user-mode PCI and other drivers. The first step is to be able to handle interrupts from user space. Subsequent patches add infrastructure for setting up DMA for PCI devices. -- 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/
Re: User mode drivers: part 1, interrupt handling (patch for 2.6.11)
We have some customers doing high performance raw I/O from various PCI VME cards. They can already mmap() and do DMA from user space to the cards. Allowing them to do interrupt processing in user space allows them to keep everything in one tight package. The ULI web site talks about this a little more. Thanks, Michael On Fri, Mar 11, 2005 at 09:25:14AM -0800, Greg KH wrote: On Fri, Mar 11, 2005 at 07:50:32AM -0600, Michael Raymond wrote: I have many users asking for something like this. Why would a user care about this? Now hardware companies that want to write closed drivers is another thing :) thanks, greg k-h -- 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/
Re: Linux-Kernel Archive: No 100 HZ timer !
On Fri, Apr 13, 2001 at 08:20:56AM -0400, Mark Salisbury wrote: > inner loop, i.e. interrupt timer code should never have to convert from some > real time value into number of decrementer ticks in order to set up the next > interrupt as that requires devides (and 64 bit ones at that) in a tickless > system. > > this is why any variable interval list/heap/tree/whatever should be kept in > local ticks. frequently used values can be pre-computed at boot time to > speed up certain calculations (like how many local ticks/proc quantum) What about machines without synchronized local ticks? We're going to have to end up doing conversions anyway because of drift and machines without even the same speed CPUs. A time based system using local cached values such as cycles_per_usec would better be able to handle this. Michael -- Michael A. Raymond Office: (651) 683-3434 Irix Core Kernel Group - 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/
Re: Linux-Kernel Archive: No 100 HZ timer !
On Fri, Apr 13, 2001 at 08:20:56AM -0400, Mark Salisbury wrote: inner loop, i.e. interrupt timer code should never have to convert from some real time value into number of decrementer ticks in order to set up the next interrupt as that requires devides (and 64 bit ones at that) in a tickless system. this is why any variable interval list/heap/tree/whatever should be kept in local ticks. frequently used values can be pre-computed at boot time to speed up certain calculations (like how many local ticks/proc quantum) What about machines without synchronized local ticks? We're going to have to end up doing conversions anyway because of drift and machines without even the same speed CPUs. A time based system using local cached values such as cycles_per_usec would better be able to handle this. Michael -- Michael A. Raymond Office: (651) 683-3434 Irix Core Kernel Group - 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/
