[lkml]   [2009]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] kvm: remove in_range from kvm_io_device
    On Tue, Jun 23, 2009 at 11:21:53AM -0400, Gregory Haskins wrote:
    > Michael S. Tsirkin wrote:
    > > Remove in_range from kvm_io_device and ask read/write callbacks, if
    > > supplied, to perform range checks internally. This allows aliasing
    > > (mostly for in-kernel virtio), as well as better error handling by
    > > making it possible to pass errors up to userspace. And it's enough to
    > > look at the diffstat to see that it's a better API anyway.
    > >
    > > While we are at it, document locking rules for kvm_io_device.
    > >
    > Sorry, not trying to be a PITA, but I liked your last suggestion better. :(
    > I am thinking forward to when we want to use something smarter than a
    > linear search (like rbtree/radix) for scaling the number of "devices"
    > (really, virtio-rings) that we support.

    in_range is broken for this anyway: you need more than a boolean
    predicate to implement rbtree/radix

    > The current device-count
    > target is 512, which we will begin to rapidly consume as the in-kernel
    > virtio work progresses.

    That's a large number. I had in mind more like 4 virtio devices, for
    starters: 1 for each virtqueue in net and block.

    > This proposed approach forces us into a
    > potential O(256) algorithm in the hotpath (all MMIO/PIO exits will hit
    > this, not just in-kernel users). How would you address this?

    Two ideas that come to mind:
    - add addr/len fields to devices, use these to speed up lookup
    - add a small cache that can be scanned first

    In both cases, you first do a fast lookup, ask the device whether
    it wants the transaction, then resort to linear scan if not


     \ /
      Last update: 2009-06-23 17:39    [W:0.023 / U:19.516 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site