* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Jeremy Fitzhardinge wrote:
>> Linus Torvalds wrote:
>>
>>> On Fri, 20 Jun 2008, Ingo Molnar wrote:
>>>
okay - Jeremy, could you try the fix below? (or tip/master, i just
pushed this out)
>>> Actually, don't t
Jeremy Fitzhardinge wrote:
> Linus Torvalds wrote:
>
>> On Fri, 20 Jun 2008, Ingo Molnar wrote:
>>
>>
>>> okay - Jeremy, could you try the fix below? (or tip/master, i just
>>> pushed this out)
>>>
>>>
>> Actually, don't try that one.
>>
>> It needs to be a _byte_ registers,
Linus Torvalds wrote:
> On Fri, 20 Jun 2008, Ingo Molnar wrote:
>
>> okay - Jeremy, could you try the fix below? (or tip/master, i just
>> pushed this out)
>>
>
> Actually, don't try that one.
>
> It needs to be a _byte_ registers, so "ir" was wrong. You need "iq".
>
Doesn't work, unfo
Ingo Molnar wrote:
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
>> On Fri, 20 Jun 2008, Jeremy Fitzhardinge wrote:
>>
>>> Blows up on "gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)":
>>>
>> Yeah, I was a bit worried about that. Gcc sometimes does insane
>> things.
>
On Fri, 20 Jun 2008, Ingo Molnar wrote:
>
> okay - Jeremy, could you try the fix below? (or tip/master, i just
> pushed this out)
Actually, don't try that one.
It needs to be a _byte_ registers, so "ir" was wrong. You need "iq".
Linus
_
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Fri, 20 Jun 2008, Jeremy Fitzhardinge wrote:
> >
> > Blows up on "gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)":
>
> Yeah, I was a bit worried about that. Gcc sometimes does insane
> things.
>
> We literally just tested that the as
On Fri, 20 Jun 2008, Jeremy Fitzhardinge wrote:
>
> Blows up on "gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)":
Yeah, I was a bit worried about that. Gcc sometimes does insane things.
We literally just tested that the asm should only _ever_ be generated with
a constant value, but
Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>
>> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>>
>>
>>> On Thu, 19 Jun 2008, Ingo Molnar wrote:
>>>
Below is the commit, it needed a small amount of massaging to apply the
void * -> unsigned long * change i
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 19 Jun 2008, Ingo Molnar wrote:
> > >
> > > Below is the commit, it needed a small amount of massaging to apply the
> > > void * -> unsigned long * change in the x86/bitops topic.
> >
> > W
Benjamin Herrenschmidt wrote:
>> Which architecture are you interested in? If it isn't x86, you can
>> probably get anything past Linus ;)
>>
>> I'll do some measurements to see what effect the batchable
>> ptep_set_wrprotect() has on native. If it's significant, I'll propose
>> making it cond
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Thu, 19 Jun 2008, Ingo Molnar wrote:
> >
> > Below is the commit, it needed a small amount of massaging to apply the
> > void * -> unsigned long * change in the x86/bitops topic.
>
> Well, that's your bug right there.
>
> The macros very much d
On Thu, 19 Jun 2008, Ingo Molnar wrote:
>
> Below is the commit, it needed a small amount of massaging to apply the
> void * -> unsigned long * change in the x86/bitops topic.
Well, that's your bug right there.
The macros very much depended on the pointers being "void *", due to the
pointer
> Below is the commit, it needed a small amount of massaging to apply the
> void * -> unsigned long * change in the x86/bitops topic.
So you need to change this line
> +#define CONST_MASK_ADDR BITOP_ADDR(addr + (nr>>3))
to be
#define CONST_MASK_ADDR BITOP_ADDR((void *)addr + (nr>>3))
or someth
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> config and crashlog can be found at:
>
> http://redhat.com/~mingo/misc/config-Thu_Jun_19_13_45_21_CEST_2008.bad
> http://redhat.com/~mingo/misc/crash-Thu_Jun_19_13_45_21_CEST_2008.log
just in case it helps, and for completeness, a 64-bit box blew u
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Wed, 18 Jun 2008, Linus Torvalds wrote:
> >
> > And yes, the "lock andl" should be noticeably faster than the xchgl.
>
> I dunno. Here's a untested (!!) patch that turns constant-bit
> set/clear_bit ops into byte mask ops (lock orb/andb).
>
> I
> Which architecture are you interested in? If it isn't x86, you can
> probably get anything past Linus ;)
>
> I'll do some measurements to see what effect the batchable
> ptep_set_wrprotect() has on native. If it's significant, I'll propose
> making it conditional on CONFIG_PARAVIRT.
Oh, I
Benjamin Herrenschmidt wrote:
> On Wed, 2008-06-18 at 17:24 -0700, Linus Torvalds wrote:
>
>> On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
>>
>>> Along the lines of:
>>>
>> Hell no. There's a reason we have a special set_wrprotect() thing. We can
>> do it more efficiently on nati
On Wed, 18 Jun 2008, Linus Torvalds wrote:
>
> And yes, the "lock andl" should be noticeably faster than the xchgl.
I dunno. Here's a untested (!!) patch that turns constant-bit
set/clear_bit ops into byte mask ops (lock orb/andb).
It's not exactly pretty. The reason for using the byte versio
On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
>
> It's not cmpxchg, just xchg.
> In other words, is:
>
> lock btr $_PAGE_BIT_RW, (%rbx)
Well, we can actually do it as
lock andl $~_PAGE_RW,(%rbx)
although we haven't bothered (I've wanted several times to make
clear_bit() do t
On Wed, 2008-06-18 at 17:24 -0700, Linus Torvalds wrote:
>
> On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
> >
> > Along the lines of:
>
> Hell no. There's a reason we have a special set_wrprotect() thing. We can
> do it more efficiently on native hardware by just clearing the bit
> atomicall
Linus Torvalds wrote:
> On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
>
>> Along the lines of:
>>
>
> Hell no. There's a reason we have a special set_wrprotect() thing. We can
> do it more efficiently on native hardware by just clearing the bit
> atomically. No need to do the cmpxchg ga
On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
>
> Along the lines of:
Hell no. There's a reason we have a special set_wrprotect() thing. We can
do it more efficiently on native hardware by just clearing the bit
atomically. No need to do the cmpxchg games.
Linus
_
Jeremy Fitzhardinge wrote:
> Benjamin Herrenschmidt wrote:
>
>> On Mon, 2008-06-16 at 04:30 -0700, Jeremy Fitzhardinge wrote:
>>
>>
>>> The only current user of this interface is mprotect
>>>
>>>
>> Do you plan to use it with fork ultimately ?
>>
>>
>
> Good point, I'
Benjamin Herrenschmidt wrote:
> On Mon, 2008-06-16 at 04:30 -0700, Jeremy Fitzhardinge wrote:
>
>> The only current user of this interface is mprotect
>>
>
> Do you plan to use it with fork ultimately ?
>
Good point, I'd overlooked that. I guess that means using it in
ptep_set_wrprote
On Mon, 2008-06-16 at 04:30 -0700, Jeremy Fitzhardinge wrote:
>
> The only current user of this interface is mprotect
Do you plan to use it with fork ultimately ?
Ben.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://
* Hugh Dickins <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Jun 2008, Linus Torvalds wrote:
> > On Mon, 16 Jun 2008, Jeremy Fitzhardinge wrote:
> > >
> > > ptep_modify_prot_start() returns the current pte value, and puts the
> > > pte entry into a state where either the hardware will not update the
On Mon, 16 Jun 2008, Linus Torvalds wrote:
> On Mon, 16 Jun 2008, Jeremy Fitzhardinge wrote:
> >
> > ptep_modify_prot_start() returns the current pte value, and puts the
> > pte entry into a state where either the hardware will not update the
> > pte, or if it does, the updates will be preserve
On Mon, 16 Jun 2008, Jeremy Fitzhardinge wrote:
>
> ptep_modify_prot_start() returns the current pte value, and puts the
> pte entry into a state where either the hardware will not update the
> pte, or if it does, the updates will be preserved on commit.
>
> ptep_modify_prot_commit() writes
This patch adds an API for doing read-modify-write updates to a pte's
protection bits which may race against hardware updates to the pte.
After reading the pte, the hardware may asynchonously set the accessed
or dirty bits on a pte, which would be lost when writing back the
modified pte value.
The
Ingo Molnar wrote:
> * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
>
>> +/* Get the current pte state, but zero it out to make it
>> + non-present, preventing the hardware from asynchronously
>> + updating it. */
>>
>
> please use standard and consistent comment style,
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> + /* Get the current pte state, but zero it out to make it
> +non-present, preventing the hardware from asynchronously
> +updating it. */
please use standard and consistent comment style, similar to:
> +/*
> + * Start a pte
This patch adds an API for doing read-modify-write updates to a pte's
protection bits which may race against hardware updates to the pte.
After reading the pte, the hardware may asynchonously set the accessed
or dirty bits on a pte, which would be lost when writing back the
modified pte value.
The
32 matches
Mail list logo
