On 02/22/2014 11:56 AM, Ingo Molnar wrote:
* Peter Zijlstra wrote:
On Mon, Feb 17, 2014 at 02:47:03PM -0800, H. Peter Anvin wrote:
This is starting to look good, so I have pulled it into
tip:x86/spinlocks to start give it some testing mileage.
Its still atrociously ugly code please drop it.
* Peter Zijlstra wrote:
> On Mon, Feb 17, 2014 at 02:47:03PM -0800, H. Peter Anvin wrote:
> > This is starting to look good, so I have pulled it into
> > tip:x86/spinlocks to start give it some testing mileage.
>
> Its still atrociously ugly code please drop it.
Fair enough - I've excluded it
On Fri, Feb 21, 2014 at 9:02 AM, Waiman Long wrote:
> On 02/20/2014 02:32 PM, Raghavendra K T wrote:
>>
>> On 02/20/2014 11:24 PM, Waiman Long wrote:
>>
>>> Now the key is how to detect if a kernel is really running in a PV
>>> environment. I need to ask some virtualization experts on that.
>>>
>>
On 02/20/2014 02:32 PM, Raghavendra K T wrote:
On 02/20/2014 11:24 PM, Waiman Long wrote:
Now the key is how to detect if a kernel is really running in a PV
environment. I need to ask some virtualization experts on that.
For kvm you could just follow,
kvm_spinlock_init_jump() and KVM_FEATURE
On 02/20/2014 11:24 PM, Waiman Long wrote:
Now the key is how to detect if a kernel is really running in a PV
environment. I need to ask some virtualization experts on that.
For kvm you could just follow,
kvm_spinlock_init_jump() and KVM_FEATURE_* encoding in cpuid
part __do_cpuid_ent().
--
On 02/20/2014 01:42 PM, Linus Torvalds wrote:
On Thu, Feb 20, 2014 at 9:54 AM, Waiman Long wrote:
I think we could implement 2 versions of _raw_spin_lock.
Yup. Or rather, I'd suggest implement just one version of
arch_spin_lock(), but at the top of it you do something like
#if CONFIG_PAR
On Thu, Feb 20, 2014 at 9:54 AM, Waiman Long wrote:
>
> I think we could implement 2 versions of _raw_spin_lock.
Yup. Or rather, I'd suggest implement just one version of
arch_spin_lock(), but at the top of it you do something like
#if CONFIG_PARAVIRT_SPINLOCK
if (static_key_false(&u
On Thu, Feb 20, 2014 at 12:37:14PM -0500, Waiman Long wrote:
> Yes, that is true for paravirt, but I was talking about virtualization in
> general.
Them we really don't care about :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@v
On 02/19/2014 03:17 PM, Linus Torvalds wrote:
On Wed, Feb 19, 2014 at 11:24 AM, Waiman Long wrote:
We do have a CONFIG_PARAVIRT macro that turns on or off PV support. The
queue spinlock can be easily changed into an unfair lock which allows lock
stealing. We could have a config option to make i
On Thu, Feb 20, 2014 at 9:37 AM, Waiman Long wrote:
>
> Yes, that is true for paravirt, but I was talking about virtualization in
> general.
For non-paravirtualized environments, we should basically optimize for
the actual hardware, and assume that the full virtualization is good
enough that we d
On 02/19/2014 02:48 PM, Peter Zijlstra wrote:
On Wed, Feb 19, 2014 at 02:24:49PM -0500, Waiman Long wrote:
On 02/19/2014 03:51 AM, Peter Zijlstra wrote:
On Tue, Feb 18, 2014 at 07:42:20PM -0500, Waiman Long wrote:
On 02/18/2014 04:28 PM, Peter Zijlstra wrote:
On Tue, Feb 18, 2014 at 02:30:12P
On 02/19/2014 11:24 AM, Waiman Long wrote:
> On 02/19/2014 03:51 AM, Peter Zijlstra wrote:
>> On Tue, Feb 18, 2014 at 07:42:20PM -0500, Waiman Long wrote:
>>> On 02/18/2014 04:28 PM, Peter Zijlstra wrote:
On Tue, Feb 18, 2014 at 02:30:12PM -0500, Waiman Long wrote:
> I will start looking a
On Wed, Feb 19, 2014 at 11:24 AM, Waiman Long wrote:
>
> We do have a CONFIG_PARAVIRT macro that turns on or off PV support. The
> queue spinlock can be easily changed into an unfair lock which allows lock
> stealing. We could have a config option to make it unfair in the PARAVIRT
> environment, b
On Wed, Feb 19, 2014 at 02:24:49PM -0500, Waiman Long wrote:
> On 02/19/2014 03:51 AM, Peter Zijlstra wrote:
> >On Tue, Feb 18, 2014 at 07:42:20PM -0500, Waiman Long wrote:
> >>On 02/18/2014 04:28 PM, Peter Zijlstra wrote:
> >>>On Tue, Feb 18, 2014 at 02:30:12PM -0500, Waiman Long wrote:
> I wi
On 02/19/2014 03:51 AM, Peter Zijlstra wrote:
On Tue, Feb 18, 2014 at 07:42:20PM -0500, Waiman Long wrote:
On 02/18/2014 04:28 PM, Peter Zijlstra wrote:
On Tue, Feb 18, 2014 at 02:30:12PM -0500, Waiman Long wrote:
I will start looking at how to make it work with paravirt. Hopefully, it
won't t
On Tue, Feb 18, 2014 at 07:42:20PM -0500, Waiman Long wrote:
> On 02/18/2014 04:28 PM, Peter Zijlstra wrote:
> >On Tue, Feb 18, 2014 at 02:30:12PM -0500, Waiman Long wrote:
> >>I will start looking at how to make it work with paravirt. Hopefully, it
> >>won't take too long.
> >The cheap way out is
On 02/19/2014 06:12 AM, Waiman Long wrote:
On 02/18/2014 04:28 PM, Peter Zijlstra wrote:
On Tue, Feb 18, 2014 at 02:30:12PM -0500, Waiman Long wrote:
I will start looking at how to make it work with paravirt. Hopefully, it
won't take too long.
The cheap way out is to simply switch to the test-
On 02/18/2014 04:28 PM, Peter Zijlstra wrote:
On Tue, Feb 18, 2014 at 02:30:12PM -0500, Waiman Long wrote:
I will start looking at how to make it work with paravirt. Hopefully, it
won't take too long.
The cheap way out is to simply switch to the test-and-set spinlock on
whatever X86_FEATURE_ in
On Tue, Feb 18, 2014 at 02:30:12PM -0500, Waiman Long wrote:
> I will start looking at how to make it work with paravirt. Hopefully, it
> won't take too long.
The cheap way out is to simply switch to the test-and-set spinlock on
whatever X86_FEATURE_ indicates a guest I suppose.
--
To unsubscribe
On 02/18/2014 02:31 AM, Peter Zijlstra wrote:
On Mon, Feb 17, 2014 at 02:47:03PM -0800, H. Peter Anvin wrote:
On 02/17/2014 12:41 PM, Waiman Long wrote:
v3->v4:
- Remove debugging code and fix a configuration error
- Simplify the qspinlock structure and streamline the code to make it
pe
On 02/17/2014 05:47 PM, H. Peter Anvin wrote:
On 02/17/2014 12:41 PM, Waiman Long wrote:
v3->v4:
- Remove debugging code and fix a configuration error
- Simplify the qspinlock structure and streamline the code to make it
perform a bit better
- Add an x86 version of asm/qspinlock.h for
On 02/17/2014 11:31 PM, Peter Zijlstra wrote:
>>
>> This is starting to look good, so I have pulled it into
>> tip:x86/spinlocks to start give it some testing mileage.
>
> It very much needs paravirt muck before we can even consider it.
>
Ah yes. Joy ... I so love PV.
-hpa
--
To unsub
On Mon, Feb 17, 2014 at 02:47:03PM -0800, H. Peter Anvin wrote:
> This is starting to look good, so I have pulled it into
> tip:x86/spinlocks to start give it some testing mileage.
Its still atrociously ugly code please drop it.
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Mon, Feb 17, 2014 at 02:47:03PM -0800, H. Peter Anvin wrote:
> On 02/17/2014 12:41 PM, Waiman Long wrote:
> > v3->v4:
> > - Remove debugging code and fix a configuration error
> > - Simplify the qspinlock structure and streamline the code to make it
> >perform a bit better
> > - Add an x8
On 02/17/2014 12:41 PM, Waiman Long wrote:
> v3->v4:
> - Remove debugging code and fix a configuration error
> - Simplify the qspinlock structure and streamline the code to make it
>perform a bit better
> - Add an x86 version of asm/qspinlock.h for holding x86 specific
>optimization.
>
v3->v4:
- Remove debugging code and fix a configuration error
- Simplify the qspinlock structure and streamline the code to make it
perform a bit better
- Add an x86 version of asm/qspinlock.h for holding x86 specific
optimization.
- Add an optimized x86 code path for 2 contending tasks t
26 matches
Mail list logo
