lkml.org 
[lkml]   [2015]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/9] qspinlock stuff -v15
    On Wed, Mar 25, 2015 at 03:47:39PM -0400, Konrad Rzeszutek Wilk wrote:
    > Ah nice. That could be spun out as a seperate patch to optimize the existing
    > ticket locks I presume.

    Yes I suppose we can do something similar for the ticket and patch in
    the right increment. We'd need to restructure the code a bit, but
    its not fundamentally impossible.

    We could equally apply the head hashing to the current ticket
    implementation and avoid the current bitmap iteration.

    > Now with the old pv ticketlock code an vCPU would only go to sleep once and
    > be woken up when it was its turn. With this new code it is woken up twice
    > (and twice it goes to sleep). With an overcommit scenario this would imply
    > that we will have at least twice as many VMEXIT as with the previous code.

    An astute observation, I had not considered that.

    > I presume when you did benchmarking this did not even register? Thought
    > I wonder if it would if you ran the benchmark for a week or so.

    You presume I benchmarked :-) I managed to boot something virt and run
    hackbench in it. I wouldn't know a representative virt setup if I ran
    into it.

    The thing is, we want this qspinlock for real hardware because its
    faster and I really want to avoid having to carry two spinlock
    implementations -- although I suppose that if we really really have to
    we could.


    \
     
     \ /
      Last update: 2015-03-26 22:01    [W:8.195 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site