Am 02.11.2010 20:14, Michael S. Tsirkin wrote: >>> BTW block userspace access uses a global spinlock which will likely hurt >>> us on multi-CPU. Switching that to something more SMP friendly, e.g. a >>> per-device spinlock, might be a good idea: I don't see why that lock and >>> queue are global. >> >> Been through that code recently, hairy stuff. pci_lock also protects the >> bus operation which can be overloaded (e.g. for error injection - if >> that is not the only use case). So we need a per-bus lock, but that can >> still cause contentions if devices on the same bus are handled on >> different cpus. > > Right. So this lock got reused for blocking userspace, I do not suggest > we rip it all out, just make userspace blocking use > a finer-grained lock. > >> I think the whole PCI config interface is simply not designed for >> performance. It's considered a slow path, which it normally is. > > So I guess we'll need to fix that now, at least if we > want to make the 2.3 way the default. > On many systems (those with "direct" PCI config access), there is another lock down the road: pci_config_lock. That can't be broken up as the protected resource is unique. So we do not gain much improving the higher-level lock. BTW, accessing the interrupt controller for IRQ line fiddling is not a per-device thing either. So as long as the latency of the code under the locks is not significantly worse with PCI-level masking, we don't lose scalability here. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
