On 2011-07-19 12:32, Avi Kivity wrote: > On 07/19/2011 01:17 PM, Sasha Levin wrote: >> On Tue, 2011-07-19 at 12:59 +0300, Avi Kivity wrote: >> > On 07/19/2011 12:53 PM, Sasha Levin wrote: >> > > > Make these per-guest instead of global. The lock may be >> contended, and >> > > > the list shouldn't hold items from different guests (why is >> it needed, >> > > > anyway?) >> > > > >> > > >> > > We only need the list for removal, since we only have the range >> we want >> > > to remove, and we want to find all devices which contain this >> range. >> > > >> > >> > All devices in the same guest which contain this range. Your patch >> > removes devices from all guests. >> > >> >> Yup. I've messed up guest-locality. Will fix. >> >> Also, I found this comment when increasing NR_IOBUS_DEVS: >> >> /* >> * It would be nice to use something smarter than a linear search, >> TBD... >> * Thankfully we dont expect many devices to register (famous last >> words :), >> * so until then it will suffice. At least its abstracted so we can >> change >> * in one place. >> */ >> >> Since so far we've registered 5-6 devices, and now it may increase >> significantly (since we may want to do the same change to ioeventfds, >> which work the same way) - how would you feel if we make devices >> register range(s) and do a rbtree lookup instead of a linear search? >> > > It makes sense. In fact your change is a good first step - so far it > was impossible to to a clever search since the seaching code was not > aware of the ranges (and could not be, since the single coalesced mmio > device had multiple ranges). > > Rather than an rbtree, I suggest putting all ranges in an array and > sorting it, then using binary search. Another improvement - unfortunately less transparent for user space - would be to overcome the single ring buffer that forces us to hold a central lock in user space while processing the entries. We rather need per-device rings. While waiting for coalesced VGA MMIO being processed, way too many kittens are killed. I have this on our agenda, but I wouldn't be disappointed as well if someone else is faster. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
