lkml.org 
[lkml]   [2012]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RFC V6 0/11] Paravirtualized ticketlocks
    On 03/21/2012 12:20 PM, Raghavendra K T wrote:
    > From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
    >
    > Changes since last posting: (Raghavendra K T)
    > [
    > - Rebased to linux-3.3-rc6.
    > - used function+enum in place of macro (better type checking)
    > - use cmpxchg while resetting zero status for possible race
    > [suggested by Dave Hansen for KVM patches ]
    > ]
    >
    > This series replaces the existing paravirtualized spinlock mechanism
    > with a paravirtualized ticketlock mechanism.
    >
    > Ticket locks have an inherent problem in a virtualized case, because
    > the vCPUs are scheduled rather than running concurrently (ignoring
    > gang scheduled vCPUs). This can result in catastrophic performance
    > collapses when the vCPU scheduler doesn't schedule the correct "next"
    > vCPU, and ends up scheduling a vCPU which burns its entire timeslice
    > spinning. (Note that this is not the same problem as lock-holder
    > preemption, which this series also addresses; that's also a problem,
    > but not catastrophic).
    >
    > (See Thomas Friebel's talk "Prevent Guests from Spinning Around"
    > http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.)
    >
    > Currently we deal with this by having PV spinlocks, which adds a layer
    > of indirection in front of all the spinlock functions, and defining a
    > completely new implementation for Xen (and for other pvops users, but
    > there are none at present).
    >
    > PV ticketlocks keeps the existing ticketlock implemenentation
    > (fastpath) as-is, but adds a couple of pvops for the slow paths:
    >
    > - If a CPU has been waiting for a spinlock for SPIN_THRESHOLD
    > iterations, then call out to the __ticket_lock_spinning() pvop,
    > which allows a backend to block the vCPU rather than spinning. This
    > pvop can set the lock into "slowpath state".
    >
    > - When releasing a lock, if it is in "slowpath state", the call
    > __ticket_unlock_kick() to kick the next vCPU in line awake. If the
    > lock is no longer in contention, it also clears the slowpath flag.
    >
    > The "slowpath state" is stored in the LSB of the within the lock tail
    > ticket. This has the effect of reducing the max number of CPUs by
    > half (so, a "small ticket" can deal with 128 CPUs, and "large ticket"
    > 32768).
    >
    > This series provides a Xen implementation, but it should be
    > straightforward to add a KVM implementation as well.
    >

    Looks like a good baseline on which to build the KVM implementation. We
    might need some handshake to prevent interference on the host side with
    the PLE code.

    --
    error compiling committee.c: too many arguments to function



    \
     
     \ /
      Last update: 2012-03-26 16:35    [W:0.027 / U:90.448 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site