On Thu, 30 Jul 2015, Peter Hurley wrote: > 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 agree. > 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. irq probe is a known to be unreliable heuristic endavour anyway and it cannot ever become truly reliable, except you put a gazillion of restrictions to the system state on it. > 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? First of all, there is no guarantee that you can affine these interrupts at all. We have interrupt controllers which cannot set the affinity and they deliver to cpus in a round robin scheme or whatever hardware designers thought would be clever. Second, what prevents the following scenario on UP or the affine core: probe_start() interrupt looong running handler (usb is an obvious candidate) printk() That will swallow your uart state and ruin detection as well. So for the problem at hand, we really need to prevent that something is fiddling with the uart in the first place and the most obvious way is to serialize against printk. We can debate whether the autoprobe code is the right place or not, we can actually stick it into the 8250 driver and be done with it because: If you look at the actual autoprobe users aside of 8250. That's really all ancient ISA hardware and hardly interesting. So all we really care about are the 8250 serial ports. Now lets look at the 8250 serial ports. I just checked the random collection of machines I have access to: In 100% of all cases ttyS0 is on irq4 and ttyS1 is on irq3 All of the machines have even a correct PNP entry of the irq resource for the serial ports. And there is pretty old crap in that lot. So the real question is: Why would we autoprobe in the first place? Debian, Fedora, OpenSuse, SLES have: # CONFIG_SERIAL_8250_DETECT_IRQ is not set and so do my kernels. I just built one with that option enabled for the fun of it and it still uses the PNP information. No autoprobing. So why are you interested in that serial irq autoprobe crap at all? Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
