On 2012-04-04 11:55, Avi Kivity wrote: > On 04/04/2012 12:38 PM, Jan Kiszka wrote: >> On 2012-04-04 11:36, Avi Kivity wrote: >>> On 04/04/2012 12:22 PM, Jan Kiszka wrote: >>>>> >>>>>>> Until we do have this fast path we can just fill this value with zeros, >>>>>>> so kernel patch (almost) does not need to change for this - >>>>>>> just the header. >>>>>> >>>>>> Partially implemented interfaces invite breakage. >>>>> >>>>> Hmm true. OK scrap this idea then, it's not clear >>>>> whether we are going to optimize this anyway. >>>>> >>>> >>>> Also, the problem is that keeping that ID in userspace requires an >>>> infrastructure like the MSIRoutingCache that I proposed originally. Not >>>> much won /wrt invasiveness there. >>> >>> Internal qemu refactorings are not a driver for kvm interface changes. >> >> No, but qemu demonstrates the applicability and handiness of the kernel >> interfaces. > > True. > >>> >>>> So we should really do the routing >>>> optimization in the kernel - one day. >>> >>> No, we need to make a choice: >>> >>> explicit handles: array lookup, more expensive setup >>> no handles: hash loopup, more expensive, but no setup, and no artificial >>> limits >> >> ...and I think we should head for option 2. > > I'm not so sure anymore. Sorry about the U turn, but remind me why? In > the long term it will be slower. Likely not measurably slower. If you look at a message through the arch glasses, you can usually spot the destination directly, specifically if a message targets a single processor - no need for hashing and table lookups in the common case. In contrast, the maintenance costs for the current explicit route based model are significant as we see now. 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
