On Fri, 21 Jan 2011 09:10:06 +0100 Geert Uytterhoeven ge...@linux-m68k.org
wrote:
include/linux/mutex.h:
/*
* NOTE: mutex_trylock() follows the spin_trylock() convention,
* not the down_trylock() convention!
*
* Returns 1 if the mutex has been acquired successfully, and 0 on
On Thu, Jan 20, 2011 at 05:38:33PM +0900, Simon Horman wrote:
[ Trimmed Eric from CC list as vger was complaining that it is too long ]
On Tue, Jan 18, 2011 at 11:41:22AM -0800, Rick Jones wrote:
So it won't be all that simple to implement well, and before we try,
I'd like to know whether
On Thu, Jan 20, 2011 at 09:56:27AM -0800, Jeremy Fitzhardinge wrote:
The key here is not to
sleep when waiting for locks (as implemented by current patch-series, which
can
put other VMs at an advantage by giving them more time than they are
entitled
to)
Why? If a VCPU can't
On 01/21/2011 09:02 AM, Srivatsa Vaddagiri wrote:
On Thu, Jan 20, 2011 at 09:56:27AM -0800, Jeremy Fitzhardinge wrote:
The key here is not to
sleep when waiting for locks (as implemented by current patch-series, which
can
put other VMs at an advantage by giving them more time than they are
[Just a gentle reminder that the deadline is only one week away]
Call for Papers
7th IEEE International Workshop on
Storage Network Architecture and Parallel I/Os
I have constructed a test where I run an un-paced UDP_STREAM test in
one guest and a paced omni rr test in another guest at the same time.
Hmm, what is this supposed to measure? Basically each time you run an
un-paced UDP_STREAM you get some random load on the network.
Well, if the
On Fri, Jan 21, 2011 at 11:59:30AM +0200, Michael S. Tsirkin wrote:
On Thu, Jan 20, 2011 at 05:38:33PM +0900, Simon Horman wrote:
[ Trimmed Eric from CC list as vger was complaining that it is too long ]
On Tue, Jan 18, 2011 at 11:41:22AM -0800, Rick Jones wrote:
So it won't be all that
On Fri, Jan 21, 2011 at 09:48:29AM -0500, Rik van Riel wrote:
Why? If a VCPU can't make progress because its waiting for some
resource, then why not schedule something else instead?
In the process, something else can get more share of cpu resource than its
entitled to and that's where I was
