Re: [RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid irq=0 for console

[Peter Hurley <peter@hurleysoftware.com>]

On 07/30/2015 06:12 AM, Thomas Gleixner wrote:
> On Thu, 30 Jul 2015, Taichi Kageyama wrote:
>> On 2015/07/29 22:35, Thomas Gleixner wrote:
>> I know your code is sample (console.h is required), 
>> but it is conflict with [patch v2 1/3].
>> I think serial8250_console_write should not touch ctrl reg during autoconfig_irq. 
>> To resolve the real problem, I think keeping only [patch v2 1/3] is best(opt1).
>> What do you think?
>>
>> opt1. keep [patch v2 1/3]
>>     + Don't touch other legacy drivers using autoprobe.
>>        Each driver can use console_lock to fix this problem if it happens.
> 
> No, we already know that autoprobing and console access can cause
> this, so we fix it at the core code and be done with it.
>  
> Can you please test Peters patch and confirm that is solves it.

Honestly, I'm not too sure this is the way to go.

Messing around with irqsoff tracer for 30 mins turned up:
3.664ms in intel_unmap_page
  - iotlb flush, spinlock contention on iova_rbtree_lock
1.726ms in intel_map_page()
  - iommu core @ __alloc_and_insert_iova_range()
1.859ms in syslog_print_all()
  - which is holding the logbuf_lock so that's pretty bad anyway
387us in nouveau @ nv50_vm_flush()
  - gpu tlb flush

I have irqsoff trace reports for all of these if anyone is interested.

Looks like lockdep would need to be off as well because I saw but
failed to capture a save_trace() in the 300us range.

I think this is just the tip of the iceberg for irqsoff.

I'm not saying these don't need fixing as well, but there's no way
irq probe will ever be reliable with this approach.

Going back to the RFC idea of pinning the irq affinity to the cpu
actually doing the probing (which is in a known context), what about
that is broken on UP? Just the implementation or is it the fundamental
concept?

Regards,
Peter Hurley