Jürgen Keil <> wrote: >> >> I know that all USB host controllers interrupt *really* frequently. >> >> (1000Hz.) This is a flaw in the way those interfaces were designed. >> >> Its true when *any* device is plugged into the port, I believe. >> > >> > Maybe the usb host controllers access system memory that >> > frequently, but they don't interrupt 1000 times a second >> >> Performance counter can help to check if CPU has memory access, >> but how to check memory access if it's caused by the DMA from >> USB host controller? If we don't see many interrupts from USB, >> can we say we don't have frequent DMA from USB host controller? > > As far as I understand it, the USB host controller should access > data structures in memory using DMA every millisecond,
Is this by hardware automatically or by the software driver? > but this may not lead to any interrupts. Interrupt is not the root cause. We are talking about package C-state, not per-CPU deep C-state. As I mentioned above, we measured ~99% Core C-state residency, while package C-state residency is almost 0. There are some logic in the ucode/pcode on the CPU. The bus activity could be the case to throttle package c-state to reduce access latency. > >> > (unless there is an usb device plugged in that really needs >> > to send 1000 interrupts per second). >> > Check with intrstat. >> >> intrstat can't help to shot. The interrupt number is the same on >> the problematic system and the normal system. > > I wonder if one system has the IOMMU enabled > and the other has it disabled? Doesn't a DMA > access without IOMMU bypass the cpu's MMU; > but when the IOMMU is enabled the cpu / mmu > may have to wake up when a device access > memory via DMA? > -- Already checked, both with IOMMU disabled. Thanks, -Aubrey _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
