Re: [RFC][PATCH] x86: Lazy disabling of interrupts
On Thu, Oct 10, 2013 at 5:57 PM, Steven Rostedt (by way of Steven Rostedt ) (by way of Steven Rostedt wrote: > > [ Resending, as somehow Claws email, removed the quotes from "H. Peter > Anvin", and that prevented LKML from receiving this ] > > *** NOT FOR INCLUSION *** > > What this does > -- > > There's several locations in the kernel that disable interrupts and > enable them rather quickly. Most likely an interrupt will not happen > during this time frame. Instead of actually disabling interrupts, set > a flag instead, and if an interrupt were to come in, it would see > the flag set and return (keeping interrupts disabled for real). When > the flag is cleared, it checks if an interrupt came in and if it did > it simulates that interrupt. I think the concept is similar to the linux core interrupt code handling where it does the lazy disabling of interrupt. I was just wondering if we can do the same concept for ARM arch and if some part of your code can be shared.It would be nice academic exercise. > > Rational > > I noticed in function tracing that disabling interrupts is quite > expensive. To measure this, I ran the stack tracer and several runs of > hackbench: > > trace-cmd stack --start > for i in `seq 10` ; do time ./hackbench 100; done &> output > > The stack tracer uses function tracing to examine every function's stack > as the function is executed. If it finds a stack larger than the last > max stack, it records it. But most of the time it just does the check > and returns. To do this safely (using per cpu variables), it disables > preemption: > > kernel/trace/trace_stack.c: stack_trace_call() > > preempt_disable_notrace(); > [...] > check_stack(ip, ); > [...] > preempt_enable_notrace(); > > Most of the time, check_stack() just returns without doing anything > as it is unlikely to hit a new max (it does very seldom), and shouldn't > be an issue in the benchmarks. > > Then I changed this code do be: > > > kernel/trace/trace_stack.c: stack_trace_call() > > local_irq_save(flags); > [...] > check_stack(ip, ); > [...] > local_irq_restore(flags); > > And ran the test again. This caused a very large performance hit. > > Running on: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz > (4 cores HT enabled) > > Here's the differences: > > With preempt disable (10 runs): > > Time from hackbench: > avg=2.0462 > std=0.181487189630563 > > System time (from time): > avg=10.5879 > std=0.862181477416443 > > With irq disable (10 runs): > > Time from hackbench: > avg=2.7082 > std=0.12304308188598 > > System time (from time): > avg=14.6807 > std=0.313856814487116 > > A 32% performance hit when using irq disabling told me that this is > something we could improve on in normal activities. That is, avoid > disabling interrupts when possible. For the last couple of weeks I > decided to implement a "lazy irq disable" to do this. > > > The Setup > - > > I only had to touch four functions that deal with interrupts: > >o native_irq_enable() >o native_irq_disable() >o native_save_fl() >o native_restore_fl() > > As these are the basis for all other C functions that disable interrupts > (ie. local_irq_save(), local_irq_disable(), spin_lock_irq(), etc) > just modifying them made it much easier to implement. > > I added raw_* versions of each that do the real enabling and disabling. > Basically, the raw_* versions are what they currently do today. > > Per CPU > --- > > I added a couple of per cpu variables: > >o lazy_irq_disabled_flags >o lazy_irq_func >o lazy_irq_vector >o lazy_irq_on > > The lazy_irq_disabled_flags holds the state of the system. The flags > are: > > DISABLED - When set, irqs are considered disabled (whether they are for > real or not). > > TEMP_DISABLE - Set when coming from a trap or other assembly that > disables interrupts to let the native_irq_enable() know that interrupts > are really disabled, and enable them as well. > > IDLE - Used to tell the native_* functions that we are going idle and > to continue to do real interrupt disabling/enabling. > > REAL_DISABLE - Set by interrupts themselves. When interrupts are > running, (this includes softirqs), we enable and disable interrupts > normally. No lazy disabling is done from interrupt context. > > The lazy_irq_func holds the interrupt function that was to trigger when > we were in lazy irq disabled mode with interrupts enabled. Explained > below. > > The lazy_irq_vector holds the orig_rax, which is the vector that the > interrupt handler needs to know what interrupt vector was triggered. > Saved for the same use as
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
On Thu, Oct 10, 2013 at 08:30:47AM -0400, Steven Rostedt wrote: > I just looked at my Address book, and sure enough, when you save an > email with quotes, Claws will strip them when adding it to the address > book. If you use the address book to send email, then it will use it > without quotes. This can explain why Paul wasn't getting a lot of my > emails too :-/ But why does it have quotes in the CC list of the copy I have in my mbox? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
On Thu, 10 Oct 2013 11:03:00 +0200 Borislav Petkov wrote: > That's strange - I see > > "H. Peter Anvin" > > in the CC list here. Did something get mangled on the way or is Claws > acting outlook-like? > I just looked at my Address book, and sure enough, when you save an email with quotes, Claws will strip them when adding it to the address book. If you use the address book to send email, then it will use it without quotes. This can explain why Paul wasn't getting a lot of my emails too :-/ -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] x86: Lazy disabling of interrupts
[ Resending, as somehow Claws email, removed the quotes from "H. Peter Anvin", and that prevented LKML from receiving this ] *** NOT FOR INCLUSION *** What this does -- There's several locations in the kernel that disable interrupts and enable them rather quickly. Most likely an interrupt will not happen during this time frame. Instead of actually disabling interrupts, set a flag instead, and if an interrupt were to come in, it would see the flag set and return (keeping interrupts disabled for real). When the flag is cleared, it checks if an interrupt came in and if it did it simulates that interrupt. Rational I noticed in function tracing that disabling interrupts is quite expensive. To measure this, I ran the stack tracer and several runs of hackbench: trace-cmd stack --start for i in `seq 10` ; do time ./hackbench 100; done &> output The stack tracer uses function tracing to examine every function's stack as the function is executed. If it finds a stack larger than the last max stack, it records it. But most of the time it just does the check and returns. To do this safely (using per cpu variables), it disables preemption: kernel/trace/trace_stack.c: stack_trace_call() preempt_disable_notrace(); [...] check_stack(ip, ); [...] preempt_enable_notrace(); Most of the time, check_stack() just returns without doing anything as it is unlikely to hit a new max (it does very seldom), and shouldn't be an issue in the benchmarks. Then I changed this code do be: kernel/trace/trace_stack.c: stack_trace_call() local_irq_save(flags); [...] check_stack(ip, ); [...] local_irq_restore(flags); And ran the test again. This caused a very large performance hit. Running on: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (4 cores HT enabled) Here's the differences: With preempt disable (10 runs): Time from hackbench: avg=2.0462 std=0.181487189630563 System time (from time): avg=10.5879 std=0.862181477416443 With irq disable (10 runs): Time from hackbench: avg=2.7082 std=0.12304308188598 System time (from time): avg=14.6807 std=0.313856814487116 A 32% performance hit when using irq disabling told me that this is something we could improve on in normal activities. That is, avoid disabling interrupts when possible. For the last couple of weeks I decided to implement a "lazy irq disable" to do this. The Setup - I only had to touch four functions that deal with interrupts: o native_irq_enable() o native_irq_disable() o native_save_fl() o native_restore_fl() As these are the basis for all other C functions that disable interrupts (ie. local_irq_save(), local_irq_disable(), spin_lock_irq(), etc) just modifying them made it much easier to implement. I added raw_* versions of each that do the real enabling and disabling. Basically, the raw_* versions are what they currently do today. Per CPU --- I added a couple of per cpu variables: o lazy_irq_disabled_flags o lazy_irq_func o lazy_irq_vector o lazy_irq_on The lazy_irq_disabled_flags holds the state of the system. The flags are: DISABLED - When set, irqs are considered disabled (whether they are for real or not). TEMP_DISABLE - Set when coming from a trap or other assembly that disables interrupts to let the native_irq_enable() know that interrupts are really disabled, and enable them as well. IDLE - Used to tell the native_* functions that we are going idle and to continue to do real interrupt disabling/enabling. REAL_DISABLE - Set by interrupts themselves. When interrupts are running, (this includes softirqs), we enable and disable interrupts normally. No lazy disabling is done from interrupt context. The lazy_irq_func holds the interrupt function that was to trigger when we were in lazy irq disabled mode with interrupts enabled. Explained below. The lazy_irq_vector holds the orig_rax, which is the vector that the interrupt handler needs to know what interrupt vector was triggered. Saved for the same use as lazy_irq_func is. Because preempt_disable is currently a task flag, we need a per_cpu version of it for the lazy irq disabling. When irqs are disabled, the process requires that preemption is also disabled, and we need to do this with a per_cpu flag. For now, lazy_irq_on is used, and acts just like preempt_count for preventing scheduling from taking place. The Process --- Here's the basic idea of what happens. When native_irq_disable() is called, if any flag but DISABLED is set, then real interrupts are disabled. Otherwise, if DISABLED is already set, then nothing needs to be done. The DISABLED flag
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
On Thu, Oct 10, 2013 at 12:19:39AM -0400, David Miller wrote: > From: Steven Rostedt > Date: Thu, 10 Oct 2013 00:11:53 -0400 > > > > > I'm replying to my email to see if that helps make it to LKML. If it > > doesn't, I'm sorry for the noise to all I Cc'd. > > The problem is the: > > H.PeterAnvin > > in the CC list, you can't have a name with the "." charater it appear in > email headers unless the string is surrounded by double quotes. Otherwise > it's a syntax error. That's strange - I see "H. Peter Anvin" in the CC list here. Did something get mangled on the way or is Claws acting outlook-like? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
On Thu, Oct 10, 2013 at 12:19:39AM -0400, David Miller wrote: From: Steven Rostedt rost...@goodmis.org Date: Thu, 10 Oct 2013 00:11:53 -0400 I'm replying to my email to see if that helps make it to LKML. If it doesn't, I'm sorry for the noise to all I Cc'd. The problem is the: H.PeterAnvin in the CC list, you can't have a name with the . charater it appear in email headers unless the string is surrounded by double quotes. Otherwise it's a syntax error. That's strange - I see H. Peter Anvin h...@linux.intel.com in the CC list here. Did something get mangled on the way or is Claws acting outlook-like? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] x86: Lazy disabling of interrupts
2013-10-10
Thread
Steven Rostedt rost...@goodmis.org (by way of Steven Rostedt rost...@goodmis.org) (by way of Steven Rostedt
[ Resending, as somehow Claws email, removed the quotes from H. Peter Anvin, and that prevented LKML from receiving this ] *** NOT FOR INCLUSION *** What this does -- There's several locations in the kernel that disable interrupts and enable them rather quickly. Most likely an interrupt will not happen during this time frame. Instead of actually disabling interrupts, set a flag instead, and if an interrupt were to come in, it would see the flag set and return (keeping interrupts disabled for real). When the flag is cleared, it checks if an interrupt came in and if it did it simulates that interrupt. Rational I noticed in function tracing that disabling interrupts is quite expensive. To measure this, I ran the stack tracer and several runs of hackbench: trace-cmd stack --start for i in `seq 10` ; do time ./hackbench 100; done output The stack tracer uses function tracing to examine every function's stack as the function is executed. If it finds a stack larger than the last max stack, it records it. But most of the time it just does the check and returns. To do this safely (using per cpu variables), it disables preemption: kernel/trace/trace_stack.c: stack_trace_call() preempt_disable_notrace(); [...] check_stack(ip, stack); [...] preempt_enable_notrace(); Most of the time, check_stack() just returns without doing anything as it is unlikely to hit a new max (it does very seldom), and shouldn't be an issue in the benchmarks. Then I changed this code do be: kernel/trace/trace_stack.c: stack_trace_call() local_irq_save(flags); [...] check_stack(ip, stack); [...] local_irq_restore(flags); And ran the test again. This caused a very large performance hit. Running on: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (4 cores HT enabled) Here's the differences: With preempt disable (10 runs): Time from hackbench: avg=2.0462 std=0.181487189630563 System time (from time): avg=10.5879 std=0.862181477416443 With irq disable (10 runs): Time from hackbench: avg=2.7082 std=0.12304308188598 System time (from time): avg=14.6807 std=0.313856814487116 A 32% performance hit when using irq disabling told me that this is something we could improve on in normal activities. That is, avoid disabling interrupts when possible. For the last couple of weeks I decided to implement a lazy irq disable to do this. The Setup - I only had to touch four functions that deal with interrupts: o native_irq_enable() o native_irq_disable() o native_save_fl() o native_restore_fl() As these are the basis for all other C functions that disable interrupts (ie. local_irq_save(), local_irq_disable(), spin_lock_irq(), etc) just modifying them made it much easier to implement. I added raw_* versions of each that do the real enabling and disabling. Basically, the raw_* versions are what they currently do today. Per CPU --- I added a couple of per cpu variables: o lazy_irq_disabled_flags o lazy_irq_func o lazy_irq_vector o lazy_irq_on The lazy_irq_disabled_flags holds the state of the system. The flags are: DISABLED - When set, irqs are considered disabled (whether they are for real or not). TEMP_DISABLE - Set when coming from a trap or other assembly that disables interrupts to let the native_irq_enable() know that interrupts are really disabled, and enable them as well. IDLE - Used to tell the native_* functions that we are going idle and to continue to do real interrupt disabling/enabling. REAL_DISABLE - Set by interrupts themselves. When interrupts are running, (this includes softirqs), we enable and disable interrupts normally. No lazy disabling is done from interrupt context. The lazy_irq_func holds the interrupt function that was to trigger when we were in lazy irq disabled mode with interrupts enabled. Explained below. The lazy_irq_vector holds the orig_rax, which is the vector that the interrupt handler needs to know what interrupt vector was triggered. Saved for the same use as lazy_irq_func is. Because preempt_disable is currently a task flag, we need a per_cpu version of it for the lazy irq disabling. When irqs are disabled, the process requires that preemption is also disabled, and we need to do this with a per_cpu flag. For now, lazy_irq_on is used, and acts just like preempt_count for preventing scheduling from taking place. The Process --- Here's the basic idea of what happens. When native_irq_disable() is called, if any flag but DISABLED is set, then real interrupts are disabled. Otherwise, if DISABLED is already set, then nothing needs to be done. The DISABLED
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
On Thu, 10 Oct 2013 11:03:00 +0200 Borislav Petkov b...@alien8.de wrote: That's strange - I see H. Peter Anvin h...@linux.intel.com in the CC list here. Did something get mangled on the way or is Claws acting outlook-like? I just looked at my Address book, and sure enough, when you save an email with quotes, Claws will strip them when adding it to the address book. If you use the address book to send email, then it will use it without quotes. This can explain why Paul wasn't getting a lot of my emails too :-/ -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
On Thu, Oct 10, 2013 at 08:30:47AM -0400, Steven Rostedt wrote: I just looked at my Address book, and sure enough, when you save an email with quotes, Claws will strip them when adding it to the address book. If you use the address book to send email, then it will use it without quotes. This can explain why Paul wasn't getting a lot of my emails too :-/ But why does it have quotes in the CC list of the copy I have in my mbox? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
On Thu, Oct 10, 2013 at 5:57 PM, Steven Rostedt rost...@goodmis.org (by way of Steven Rostedt rost...@goodmis.org) (by way of Steven Rostedt rost...@goodmis.org wrote: [ Resending, as somehow Claws email, removed the quotes from H. Peter Anvin, and that prevented LKML from receiving this ] *** NOT FOR INCLUSION *** What this does -- There's several locations in the kernel that disable interrupts and enable them rather quickly. Most likely an interrupt will not happen during this time frame. Instead of actually disabling interrupts, set a flag instead, and if an interrupt were to come in, it would see the flag set and return (keeping interrupts disabled for real). When the flag is cleared, it checks if an interrupt came in and if it did it simulates that interrupt. I think the concept is similar to the linux core interrupt code handling where it does the lazy disabling of interrupt. I was just wondering if we can do the same concept for ARM arch and if some part of your code can be shared.It would be nice academic exercise. Rational I noticed in function tracing that disabling interrupts is quite expensive. To measure this, I ran the stack tracer and several runs of hackbench: trace-cmd stack --start for i in `seq 10` ; do time ./hackbench 100; done output The stack tracer uses function tracing to examine every function's stack as the function is executed. If it finds a stack larger than the last max stack, it records it. But most of the time it just does the check and returns. To do this safely (using per cpu variables), it disables preemption: kernel/trace/trace_stack.c: stack_trace_call() preempt_disable_notrace(); [...] check_stack(ip, stack); [...] preempt_enable_notrace(); Most of the time, check_stack() just returns without doing anything as it is unlikely to hit a new max (it does very seldom), and shouldn't be an issue in the benchmarks. Then I changed this code do be: kernel/trace/trace_stack.c: stack_trace_call() local_irq_save(flags); [...] check_stack(ip, stack); [...] local_irq_restore(flags); And ran the test again. This caused a very large performance hit. Running on: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (4 cores HT enabled) Here's the differences: With preempt disable (10 runs): Time from hackbench: avg=2.0462 std=0.181487189630563 System time (from time): avg=10.5879 std=0.862181477416443 With irq disable (10 runs): Time from hackbench: avg=2.7082 std=0.12304308188598 System time (from time): avg=14.6807 std=0.313856814487116 A 32% performance hit when using irq disabling told me that this is something we could improve on in normal activities. That is, avoid disabling interrupts when possible. For the last couple of weeks I decided to implement a lazy irq disable to do this. The Setup - I only had to touch four functions that deal with interrupts: o native_irq_enable() o native_irq_disable() o native_save_fl() o native_restore_fl() As these are the basis for all other C functions that disable interrupts (ie. local_irq_save(), local_irq_disable(), spin_lock_irq(), etc) just modifying them made it much easier to implement. I added raw_* versions of each that do the real enabling and disabling. Basically, the raw_* versions are what they currently do today. Per CPU --- I added a couple of per cpu variables: o lazy_irq_disabled_flags o lazy_irq_func o lazy_irq_vector o lazy_irq_on The lazy_irq_disabled_flags holds the state of the system. The flags are: DISABLED - When set, irqs are considered disabled (whether they are for real or not). TEMP_DISABLE - Set when coming from a trap or other assembly that disables interrupts to let the native_irq_enable() know that interrupts are really disabled, and enable them as well. IDLE - Used to tell the native_* functions that we are going idle and to continue to do real interrupt disabling/enabling. REAL_DISABLE - Set by interrupts themselves. When interrupts are running, (this includes softirqs), we enable and disable interrupts normally. No lazy disabling is done from interrupt context. The lazy_irq_func holds the interrupt function that was to trigger when we were in lazy irq disabled mode with interrupts enabled. Explained below. The lazy_irq_vector holds the orig_rax, which is the vector that the interrupt handler needs to know what interrupt vector was triggered. Saved for the same use as lazy_irq_func is. Because preempt_disable is currently a task flag, we need a
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
* Andi Kleen wrote: > - That said, I think a software CLI/STI is somewhat useful for > profiling, as it can allow to measure how long interrupts are delayed by > CLI/STI. [...] That could be measured directly in a simpler way, without disrupting CLI/STI: by turning all IRQs into NMIs and resending them from a special NMI handler. (and of course timestamping the NMI arrival time and the IRQ entry time so that instrumentation can recover it.) If indirect, statistical measurement suffices then IRQ delivery latencies can also be estimated statistically without any kernel changes: by profiling IRQ disable/enable sections (there's a counter for that), calculating average IRQ-disable section length from that. The average IRQ delay will be 50% of that value, assuming normal distribution of IRQs. This should be good enough for most cases. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
From: Steven Rostedt Date: Thu, 10 Oct 2013 00:11:53 -0400 > > I'm replying to my email to see if that helps make it to LKML. If it > doesn't, I'm sorry for the noise to all I Cc'd. The problem is the: H.PeterAnvin in the CC list, you can't have a name with the "." charater it appear in email headers unless the string is surrounded by double quotes. Otherwise it's a syntax error. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
On Wed, 09 Oct 2013 23:39:28 -0400 (EDT) David Miller wrote: > From: Steven Rostedt > Date: Wed, 9 Oct 2013 20:36:27 -0400 > > > I don't know why my email never reached LKML, was there something about > > it that prevented it from going? The total character length was 46,972, > > well below the 100,000 limit. Also the Cc list wasn't that big. Did my > > ISP get flagged as a spam bot or something? > > > > I can bounce it to you to see what was wrong with it. > > That's odd, can you try sending it to the list again? I'll watch > very carefully for a bounce. > I just sent it as a redirect to LKML. Hopefully that worked. Thanks, -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
From: Steven Rostedt Date: Wed, 9 Oct 2013 20:36:27 -0400 > I don't know why my email never reached LKML, was there something about > it that prevented it from going? The total character length was 46,972, > well below the 100,000 limit. Also the Cc list wasn't that big. Did my > ISP get flagged as a spam bot or something? > > I can bounce it to you to see what was wrong with it. That's odd, can you try sending it to the list again? I'll watch very carefully for a bounce. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
On Wed, 09 Oct 2013 15:25:23 -0700 Andi Kleen wrote: > "H. Peter Anvin" writes: > > >> Summary > >> --- > >> > >> Although the extreme case shows a nice improvement, I'm skeptical if it > >> is worth doing for real world applications. > > > > You did the experiment, and credit to you for not going "I did the work, > > now include it" but rather for publishing the results so we can learn > > from them. > > > > It *does* make me wonder if we can leverage RTM for a significant subset > > of these (as an interrupt will abort a transaction); that should be > > substantially cheaper and less complex. > > I miss the original context and can't find the original patchkit, but: Yeah, for some reason, the original email didn't make it to LKML. Dave, I don't know why my email never reached LKML, was there something about it that prevented it from going? The total character length was 46,972, well below the 100,000 limit. Also the Cc list wasn't that big. Did my ISP get flagged as a spam bot or something? I can bounce it to you to see what was wrong with it. -- Steve > > - If the goal is to lower interrupt latency then RTM would still > need to use a fallback, so the worst case would be the fallback, thus > not be better. > > - If the goal is to make CLI/STI faster: > I'm not sure RTM is any faster than a PUSHF/CLI/POPF pair. It may > well be slightly slower in fact (guessing here, haven't benchmarked) > > - Also when you abort you would need to reexecute of course. > > - My TSX patchkit actually elides CLI/STI inside transactions > (no need to do them, as any interrupt would abort anyways) > but the main motivation was to avoid extra aborts. > > - That said, I think a software CLI/STI is somewhat useful for profiling, > as it can allow to measure how long interrupts are delayed > by CLI/STI. I heard use cases of this, but I'm not > sure how common it really is > > [I presume a slightly modified RT kernel could also give the same > profiling results] > > -Andi > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
"H. Peter Anvin" writes: >> Summary >> --- >> >> Although the extreme case shows a nice improvement, I'm skeptical if it >> is worth doing for real world applications. > > You did the experiment, and credit to you for not going "I did the work, > now include it" but rather for publishing the results so we can learn > from them. > > It *does* make me wonder if we can leverage RTM for a significant subset > of these (as an interrupt will abort a transaction); that should be > substantially cheaper and less complex. I miss the original context and can't find the original patchkit, but: - If the goal is to lower interrupt latency then RTM would still need to use a fallback, so the worst case would be the fallback, thus not be better. - If the goal is to make CLI/STI faster: I'm not sure RTM is any faster than a PUSHF/CLI/POPF pair. It may well be slightly slower in fact (guessing here, haven't benchmarked) - Also when you abort you would need to reexecute of course. - My TSX patchkit actually elides CLI/STI inside transactions (no need to do them, as any interrupt would abort anyways) but the main motivation was to avoid extra aborts. - That said, I think a software CLI/STI is somewhat useful for profiling, as it can allow to measure how long interrupts are delayed by CLI/STI. I heard use cases of this, but I'm not sure how common it really is [I presume a slightly modified RT kernel could also give the same profiling results] -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
> Summary > --- > > Although the extreme case shows a nice improvement, I'm skeptical if it > is worth doing for real world applications. You did the experiment, and credit to you for not going "I did the work, now include it" but rather for publishing the results so we can learn from them. It *does* make me wonder if we can leverage RTM for a significant subset of these (as an interrupt will abort a transaction); that should be substantially cheaper and less complex. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
Summary --- Although the extreme case shows a nice improvement, I'm skeptical if it is worth doing for real world applications. You did the experiment, and credit to you for not going I did the work, now include it but rather for publishing the results so we can learn from them. It *does* make me wonder if we can leverage RTM for a significant subset of these (as an interrupt will abort a transaction); that should be substantially cheaper and less complex. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
H. Peter Anvin h...@linux.intel.com writes: Summary --- Although the extreme case shows a nice improvement, I'm skeptical if it is worth doing for real world applications. You did the experiment, and credit to you for not going I did the work, now include it but rather for publishing the results so we can learn from them. It *does* make me wonder if we can leverage RTM for a significant subset of these (as an interrupt will abort a transaction); that should be substantially cheaper and less complex. I miss the original context and can't find the original patchkit, but: - If the goal is to lower interrupt latency then RTM would still need to use a fallback, so the worst case would be the fallback, thus not be better. - If the goal is to make CLI/STI faster: I'm not sure RTM is any faster than a PUSHF/CLI/POPF pair. It may well be slightly slower in fact (guessing here, haven't benchmarked) - Also when you abort you would need to reexecute of course. - My TSX patchkit actually elides CLI/STI inside transactions (no need to do them, as any interrupt would abort anyways) but the main motivation was to avoid extra aborts. - That said, I think a software CLI/STI is somewhat useful for profiling, as it can allow to measure how long interrupts are delayed by CLI/STI. I heard use cases of this, but I'm not sure how common it really is [I presume a slightly modified RT kernel could also give the same profiling results] -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
On Wed, 09 Oct 2013 15:25:23 -0700 Andi Kleen a...@firstfloor.org wrote: H. Peter Anvin h...@linux.intel.com writes: Summary --- Although the extreme case shows a nice improvement, I'm skeptical if it is worth doing for real world applications. You did the experiment, and credit to you for not going I did the work, now include it but rather for publishing the results so we can learn from them. It *does* make me wonder if we can leverage RTM for a significant subset of these (as an interrupt will abort a transaction); that should be substantially cheaper and less complex. I miss the original context and can't find the original patchkit, but: Yeah, for some reason, the original email didn't make it to LKML. Dave, I don't know why my email never reached LKML, was there something about it that prevented it from going? The total character length was 46,972, well below the 100,000 limit. Also the Cc list wasn't that big. Did my ISP get flagged as a spam bot or something? I can bounce it to you to see what was wrong with it. -- Steve - If the goal is to lower interrupt latency then RTM would still need to use a fallback, so the worst case would be the fallback, thus not be better. - If the goal is to make CLI/STI faster: I'm not sure RTM is any faster than a PUSHF/CLI/POPF pair. It may well be slightly slower in fact (guessing here, haven't benchmarked) - Also when you abort you would need to reexecute of course. - My TSX patchkit actually elides CLI/STI inside transactions (no need to do them, as any interrupt would abort anyways) but the main motivation was to avoid extra aborts. - That said, I think a software CLI/STI is somewhat useful for profiling, as it can allow to measure how long interrupts are delayed by CLI/STI. I heard use cases of this, but I'm not sure how common it really is [I presume a slightly modified RT kernel could also give the same profiling results] -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
From: Steven Rostedt rost...@goodmis.org Date: Wed, 9 Oct 2013 20:36:27 -0400 I don't know why my email never reached LKML, was there something about it that prevented it from going? The total character length was 46,972, well below the 100,000 limit. Also the Cc list wasn't that big. Did my ISP get flagged as a spam bot or something? I can bounce it to you to see what was wrong with it. That's odd, can you try sending it to the list again? I'll watch very carefully for a bounce. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
On Wed, 09 Oct 2013 23:39:28 -0400 (EDT) David Miller da...@davemloft.net wrote: From: Steven Rostedt rost...@goodmis.org Date: Wed, 9 Oct 2013 20:36:27 -0400 I don't know why my email never reached LKML, was there something about it that prevented it from going? The total character length was 46,972, well below the 100,000 limit. Also the Cc list wasn't that big. Did my ISP get flagged as a spam bot or something? I can bounce it to you to see what was wrong with it. That's odd, can you try sending it to the list again? I'll watch very carefully for a bounce. I just sent it as a redirect to LKML. Hopefully that worked. Thanks, -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
From: Steven Rostedt rost...@goodmis.org Date: Thu, 10 Oct 2013 00:11:53 -0400 I'm replying to my email to see if that helps make it to LKML. If it doesn't, I'm sorry for the noise to all I Cc'd. The problem is the: H.PeterAnvin in the CC list, you can't have a name with the . charater it appear in email headers unless the string is surrounded by double quotes. Otherwise it's a syntax error. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] x86: Lazy disabling of interrupts
* Andi Kleen a...@firstfloor.org wrote: - That said, I think a software CLI/STI is somewhat useful for profiling, as it can allow to measure how long interrupts are delayed by CLI/STI. [...] That could be measured directly in a simpler way, without disrupting CLI/STI: by turning all IRQs into NMIs and resending them from a special NMI handler. (and of course timestamping the NMI arrival time and the IRQ entry time so that instrumentation can recover it.) If indirect, statistical measurement suffices then IRQ delivery latencies can also be estimated statistically without any kernel changes: by profiling IRQ disable/enable sections (there's a counter for that), calculating average IRQ-disable section length from that. The average IRQ delay will be 50% of that value, assuming normal distribution of IRQs. This should be good enough for most cases. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
