Message-ID: <4C56DB1E.5030501@redhat.com>
Date: Mon, 02 Aug 2010 17:50:06 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.1
MIME-Version: 1.0
To: Ryan Harper <ryanh@us.ibm.com>
CC: Jeremy Fitzhardinge <jeremy@goop.org>, vatsa@linux.vnet.ibm.com,
        Marcelo Tosatti <mtosatti@redhat.com>, Gleb Natapov <gleb@redhat.com>,
        linux-kernel@vger.kernel.org, npiggin@suse.de, kvm@vger.kernel.org,
        bharata@in.ibm.com, Balbir Singh <balbir@in.ibm.com>,
        Jan Beulich <JBeulich@novell.com>
Subject: Re: [PATCH RFC 2/4] Add yield hypercall for KVM guests
References: <20100726061150.GB21699@linux.vnet.ibm.com> <20100726061445.GB8402@linux.vnet.ibm.com> <4C4DC3AD.7010404@goop.org> <4C5682A3.40409@redhat.com> <20100802144257.GN1647@us.ibm.com>
In-Reply-To: <20100802144257.GN1647@us.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1420
Lines: 31

  On 08/02/2010 05:42 PM, Ryan Harper wrote:
>
>> A problem with directed yield is figuring out who to yield to.  One idea
>> is to look for a random vcpu that is not running and donate some runtime
>> to it.  In the best case, it's the lock holder and we cause it to start
>> running.  Middle case it's not the lock holder, but we lose enough
>> runtime to stop running, so at least we don't waste cpu.  Worst case we
>> continue running not having woken the lock holder.  Spin again, yield
>> again hoping to find the right vcpu.
> It's been quite some time, but played with directed yielding for Xen[1]
> and we were looking to model the POWER directed yield (H_CONFER) where
> the lock holding vcpu was indiciated in the spinlock.  When acquiring
> the lock, record the vcpu id.  When another vcpu attempts to acquire the
> lock if it can't it can yield its time to the lock holder.

No reason why we can't have something similar.

We can take the lock and set the owner atomically:

   LOCK_PREFIX "cmpxchg %1, %0"
    : "=m"(lock) : "r"(raw_smp_processor_id() | SPIN_LOCK_BIAS), 
"a"((u16)0) : "memory"

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/