[lkml]   [2011]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: One (possible) x86 get_user_pages bug
    I agree i.e. deviation from underlying arch consideration is not a good

    Also, agreed, hypervisor knows which page entries are ready for TLB flush
    across vCPUs.

    But, using above knowledge, along with TLB flush based on IPI is a better
    solution. Its ability to synchronize it with pCPU based IPI and TLB flush
    across vCPU. is key.

    IPIs themselves should be in few hundred uSecs in terms latency. Also, why
    should pCPU be in sleep state for active vCPU scheduled page workload?


    -----Original Message-----
    From: Avi Kivity []
    Sent: Sunday, January 30, 2011 5:02 AM
    To: Jeremy Fitzhardinge
    Cc: Jan Beulich; Xiaowei Yang; Nick Piggin; Peter Zijlstra;; Kaushik Barde; Kenneth Lee; linqaingmin;; Wu Fengguang;;; Marcelo Tosatti
    Subject: Re: One (possible) x86 get_user_pages bug

    On 01/27/2011 08:27 PM, Jeremy Fitzhardinge wrote:
    > And even just considering virtualization, having non-IPI-based tlb
    > shootdown is a measurable performance win, since a hypervisor can
    > optimise away a cross-VCPU shootdown if it knows no physical TLB
    > contains the target VCPU's entries. I can imagine the KVM folks could
    > get some benefit from that as well.

    It's nice to avoid the IPI (and waking up a cpu if it happens to be
    asleep) but I think the risk of deviating too much from the baremetal
    arch is too large, as demonstrated by this bug.

    (well, async page faults is a counterexample, I wonder if/when it will
    bite us)

    error compiling committee.c: too many arguments to function

     \ /
      Last update: 2011-01-30 23:29    [W:0.020 / U:39.744 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site