Prev: Oops while running fs_racer test on a POWER6 box against latest git
Next: [GIT PULL] omap fixes for 2.6.35-rc3
From: Jan Beulich on 30 Jun 2010 07:40
>>> On 30.06.10 at 12:07, Jeremy Fitzhardinge <jeremy(a)goop.org> wrote:
> On 06/29/2010 04:32 PM, Jan Beulich wrote:
>> Use the (alternative instructions based) callout hooks to the ticket
>> spinlock code to enlighten ticket locks when running fully virtualized
>> on Xen. Ultimately, this code might also be a candidate to be used
>> when running para-virtualized.
>>
>
> I'm not sure what the gain is by making this independent of all the rest
> of the Xen support in the kernel. Stefano is working on a series
> (posted a few times now) to add more paravirtual features for Xen HVM
> guests, and this work is conceptually very similar.

The intention really is for PARAVIRT_SPINLOCKS to go away as soon
as pv-ops Xen can be switched over to this mechanism.

> Also, I'm not very keen on adding yet another kind of patching mechanism
> to the kernel. While they're easy enough to get working in the first
> place, they do tend to be fragile when other changes get introduced
> (like changes to how the kernel is mapped RO/NX, etc), and this one will
> be exercised relatively rarely. I don't see why the pvops mechanism
> couldn't be reused, especially now that each set of ops can be
> individually configured on/off.

Wasn't the main complaint with using pvops patching that it
introduced extra calls into the native execution path? The point
of this "new" (it's not really new, it's using existing infrastructure)
mechanism is just to avoid such overhead for native.

> This is especially acute in the case where you are using a full
> pvops-using PV kernel, where it ends up using two mechanisms to put
> paravirtualizations in place.

And I see nothing wrong with this - if the individual pieces are
separate anyway, why shouldn't each of them use the most
efficient technique? Or if a single mechanism is desirable, shouldn't
one rather ask to convert the newer pvops patching mechanism
to the alternative instruction patching one, as that had been in
place long before?

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jan Beulich on 1 Jul 2010 04:00
>>> On 30.06.10 at 17:57, Stefano Stabellini <stefano.stabellini(a)eu.citrix.com>
wrote:
> On Wed, 30 Jun 2010, Jeremy Fitzhardinge wrote:
>> On 06/29/2010 04:32 PM, Jan Beulich wrote:
>> > Use the (alternative instructions based) callout hooks to the ticket
>> > spinlock code to enlighten ticket locks when running fully virtualized
>> > on Xen. Ultimately, this code might also be a candidate to be used
>> > when running para-virtualized.
>> >
>>
>> I'm not sure what the gain is by making this independent of all the rest
>> of the Xen support in the kernel. Stefano is working on a series
>> (posted a few times now) to add more paravirtual features for Xen HVM
>> guests, and this work is conceptually very similar.
>
> My series has been stable since a while now and contains all the basic
> PV on HVM mechanisms you need, including parsing the cpuid and mapping
> the shared info page.
>
> Could you please rebase on my series (or at least the first two
> patches), so that we don't conflict with each other?

I really don't want to make those patches depend on no upstream
stuff (as I want it accepted upstream), and I'm not sure when your
patch series is expected to be upstream. If that's going to be soon,
I'd just re-base after it happened.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: Oops while running fs_racer test on a POWER6 box against latest git
Next: [GIT PULL] omap fixes for 2.6.35-rc3