On 07/14/2012 03:55 PM, Jan Kiszka wrote:
>>> The only way we can avoid that, is that we get a hint from the
>>> underlying irq chip/ handler setup with an extra flag to tell the
>>> core, that it's safe to avoid the ONESHOT/finalize magic.
>>
>> So now it took a full month of ignorance to come u
On 2012-07-14 14:33, Thomas Gleixner wrote:
> On Sat, 14 Jul 2012, Jan Kiszka wrote:
>> On 2012-07-14 13:16, Thomas Gleixner wrote:
>>> On Sat, 14 Jul 2012, Jan Kiszka wrote:
On 2012-07-14 04:25, Thomas Gleixner wrote:
This patch here is a workaround to unbreak devices assignment in 3.5
>
On Sat, 14 Jul 2012, Jan Kiszka wrote:
> On 2012-07-14 13:16, Thomas Gleixner wrote:
> > On Sat, 14 Jul 2012, Jan Kiszka wrote:
> >> On 2012-07-14 04:25, Thomas Gleixner wrote:
> >> This patch here is a workaround to unbreak devices assignment in 3.5
> >> after the IRQ layer changes without regress
On 2012-07-14 13:16, Thomas Gleixner wrote:
> On Sat, 14 Jul 2012, Jan Kiszka wrote:
>> On 2012-07-14 04:25, Thomas Gleixner wrote:
>> This patch here is a workaround to unbreak devices assignment in 3.5
>> after the IRQ layer changes without regressing noticeable /wrt overhead.
>
> Yeah, workarou
On Sat, 14 Jul 2012, Jan Kiszka wrote:
> On 2012-07-14 04:25, Thomas Gleixner wrote:
> This patch here is a workaround to unbreak devices assignment in 3.5
> after the IRQ layer changes without regressing noticeable /wrt overhead.
Yeah, workaround and regression are the proper marketing buzzwords
On 2012-07-14 04:25, Thomas Gleixner wrote:
> On Fri, 13 Jul 2012, Thomas Gleixner wrote:
>> On Fri, 13 Jul 2012, Linus Torvalds wrote:
>>> On Fri, Jul 13, 2012 at 8:45 AM, Linus Torvalds
>>> wrote:
>>> At the same time, I do wonder if maybe MSI + IRQF_ONESHOT couldn't be
>>> improved. The fact th
On Fri, 13 Jul 2012, Thomas Gleixner wrote:
> On Fri, 13 Jul 2012, Linus Torvalds wrote:
> > On Fri, Jul 13, 2012 at 8:45 AM, Linus Torvalds
> > wrote:
> > At the same time, I do wonder if maybe MSI + IRQF_ONESHOT couldn't be
> > improved. The fact that the KVM people think that the extra overhead
On Fri, 13 Jul 2012, Linus Torvalds wrote:
> On Fri, Jul 13, 2012 at 11:28 AM, Thomas Gleixner wrote:
> >
> > We already discussed to let the irq chip (in this case MSI) tell the
> > core that it does not need the extra oneshot handling. That way the
> > code which requests an threaded irq with t
On Fri, Jul 13, 2012 at 11:28 AM, Thomas Gleixner wrote:
>
> We already discussed to let the irq chip (in this case MSI) tell the
> core that it does not need the extra oneshot handling. That way the
> code which requests an threaded irq with the NULL primary handler
> works on both MSI and normal
On Fri, 13 Jul 2012, Linus Torvalds wrote:
> On Fri, Jul 13, 2012 at 8:45 AM, Linus Torvalds
> wrote:
> At the same time, I do wonder if maybe MSI + IRQF_ONESHOT couldn't be
> improved. The fact that the KVM people think that the extra overhead
> of IRQF_ONESHOT is a bad thing for MSI interrupts
On Fri, Jul 13, 2012 at 8:45 AM, Linus Torvalds
wrote:
> Missing diffstat. Please please *please* always make sure you have
> diffstats, because I really want to know that what I'm pulling matches
> what you *think* that I'm pulling. And the diffstat isn't just for me
> - it hopefully really makes
Missing diffstat. Please please *please* always make sure you have
diffstats, because I really want to know that what I'm pulling matches
what you *think* that I'm pulling. And the diffstat isn't just for me
- it hopefully really makes you look at the whole "this is what I'm
asking Linus to pull" t
12 matches
Mail list logo
