ty...@mit.edu writes:
> On Mon, Mar 17, 2014 at 11:12:15AM +1030, Rusty Russell wrote:
>>
>> Note that with indirect descriptors (which is supported by Almost
>> Everyone), we can actually use the full index, so this value is a bit
>> pessimistic. But it's OK as a starting point.
>
> So is this s
Joe Perches writes:
> On Sun, 2014-03-16 at 22:00 -0700, Joe Perches wrote:
>> On Mon, 2014-03-17 at 14:25 +1030, Rusty Russell wrote:
>>
>> > Erk, our tests are insufficient. Testbuilding an allmodconfig with this
>> > now:
>>
>> Good idea.
>>
>> > diff --git a/include/linux/moduleparam.h b/i
On 03/18/2014 04:14 AM, Paolo Bonzini wrote:
Il 17/03/2014 20:05, Konrad Rzeszutek Wilk ha scritto:
> Measurements were done by Gleb for two guests running 2.6.32 with 16
> vcpus each, on a 16-core system. One guest ran with unfair locks,
> one guest ran with fair locks. Two kernel compilation
On 03/17/2014 03:10 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Mar 17, 2014 at 01:44:34PM -0400, Waiman Long wrote:
On 03/14/2014 04:30 AM, Peter Zijlstra wrote:
On Thu, Mar 13, 2014 at 04:05:19PM -0400, Waiman Long wrote:
On 03/13/2014 11:15 AM, Peter Zijlstra wrote:
On Wed, Mar 12, 2014 at 02
On 03/17/2014 02:54 PM, Peter Zijlstra wrote:
On Mon, Mar 17, 2014 at 01:44:34PM -0400, Waiman Long wrote:
The PV ticketlock code was designed to handle lock holder preemption by
redirecting CPU resources in a preempted guest to another guest that can
better use it and then return the preempted
= WorldCIST'14 =
The 2014 World Conference on Information Systems and Technologies
April 15-17, Madeira Island, Portugal
http://www.aisti.eu/worldcist14/
=
Il 17/03/2014 18:47, Waiman Long ha scritto:
Yeah, what I mean is that the patches that enable paravirtualization
should also take care of decreasing the unfair-lock jump label when
paravirtualization is enabled.
As there are people who don't like unfair lock at all, I prefer to give
them the o
Il 17/03/2014 19:54, Peter Zijlstra ha scritto:
On Mon, Mar 17, 2014 at 01:44:34PM -0400, Waiman Long wrote:
The PV ticketlock code was designed to handle lock holder preemption by
redirecting CPU resources in a preempted guest to another guest that can
better use it and then return the preempte
Il 17/03/2014 20:05, Konrad Rzeszutek Wilk ha scritto:
> Measurements were done by Gleb for two guests running 2.6.32 with 16
> vcpus each, on a 16-core system. One guest ran with unfair locks,
> one guest ran with fair locks. Two kernel compilations ("time make
And when you say fair locks are