On 09/05/2014 01:14 PM, Peter Hurley wrote:
>
> Here's how I read the two statements.
>
> First, the commit message:
>
> "It [this commit] documents that CPUs [supported by the Linux kernel]
> _must provide_ atomic one-byte and two-byte naturally aligned loads and
> stores."
>
> Second, in
Paul E. McKenney wrote:
>On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
>>On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
>>> This commit documents the fact that it is not safe to use bitfields as
>>> shared variables in synchronization algorithms. It also documents that
>>> CPUs
On Fri, Sep 05, 2014 at 04:01:35PM -0400, Peter Hurley wrote:
> On 09/05/2014 03:52 PM, Peter Zijlstra wrote:
> > On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
> >> compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
> >>
> >> CPUs without single-byte and
On 09/05/2014 01:12 PM, Peter Zijlstra wrote:
>>
>> ... and I'm wondering if I should _remove_ pre-EV56 configurations or
>> move the default choice and produce a warning about unsupported Alpha
>> CPUs instead?
>>
>
> depends BROKEN
>
> or is that deprecated?
>
Just rip it out, like I did
On 09/05/2014 03:38 PM, Marc Gauthier wrote:
> Paul E. McKenney wrote:
>> On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
>>> On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
This commit documents the fact that it is not safe to use bitfields as
shared variables in
On Fri, Sep 05, 2014 at 04:01:35PM -0400, Peter Hurley wrote:
> > So does this patch depends on a patch that removes pre EV56 alpha
> > support? I'm all for removing that, but I need to see the patch merged
> > before we can do this.
>
> I'm working on that but Alpha's Kconfig is not quite
On Fri, Sep 05, 2014 at 03:24:35PM -0400, Peter Hurley wrote:
> On 09/05/2014 03:05 PM, Paul E. McKenney wrote:
> > On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
> >> On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
>
> [cut]
>
> >>>
On 09/05/2014 03:52 PM, Peter Zijlstra wrote:
> On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
>> compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
>>
>> CPUs without single-byte and double-byte loads and stores place some
>> "interesting" requirements on
On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
> compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
>
> CPUs without single-byte and double-byte loads and stores place some
> "interesting" requirements on concurrent code. For example (adapted
> from Peter
On 09/05/2014 03:05 PM, Paul E. McKenney wrote:
> On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
>> On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
[cut]
>>>
>>>
>>> documentation: Record limitations of
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
> On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
> > On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
> >> On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
> >>> On 09/04/2014 05:59 PM, Peter Hurley wrote:
>
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
> On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
>> On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
>>> On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
On Fri, Sep 05, 2014 at 11:09:50AM -0700, Paul E. McKenney wrote:
> On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
> > On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
> > > On 09/04/2014 05:59 PM, Peter Hurley wrote:
> > > > I have no idea how prevalent the ev56 is
On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
> On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
> > On 09/04/2014 05:59 PM, Peter Hurley wrote:
> > > I have no idea how prevalent the ev56 is compared to the ev5.
> > > Still we're talking about a chip that came out
On 09/05/2014 08:37 AM, David Laight wrote:
> From: Peter Hurley
>> On 09/05/2014 04:30 AM, David Laight wrote:
>>> I've seen gcc generate 32bit accesses for 16bit structure members on arm.
>>> It does this because of the more limited range of the offsets for the 16bit
>>> access.
>>> OTOH I
On 09/05/2014 08:31 AM, Peter Hurley wrote:
>
> Which is a bit ironic because I remember when Digital had a team
> working on emulating native x86 apps on Alpha/NT.
>
Right, because the x86 architecture was obsolete and would never scale...
-hpa
--
To unsubscribe from this list: send
On 09/04/2014 10:08 PM, H. Peter Anvin wrote:
> On 09/04/2014 05:59 PM, Peter Hurley wrote:
>> I have no idea how prevalent the ev56 is compared to the ev5.
>> Still we're talking about a chip that came out in 1996.
>
> Ah yes, I stand corrected. According to Wikipedia, the affected CPUs
> were
From: Peter Hurley
> [ +cc linux-arm ]
>
> Hi David,
>
> On 09/05/2014 04:30 AM, David Laight wrote:
> > I've seen gcc generate 32bit accesses for 16bit structure members on arm.
> > It does this because of the more limited range of the offsets for the 16bit
> > access.
> > OTOH I don't know if
[ +cc linux-arm ]
Hi David,
On 09/05/2014 04:30 AM, David Laight wrote:
> I've seen gcc generate 32bit accesses for 16bit structure members on arm.
> It does this because of the more limited range of the offsets for the 16bit
> access.
> OTOH I don't know if it ever did this for writes - so it
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
> On 09/04/2014 05:59 PM, Peter Hurley wrote:
> > I have no idea how prevalent the ev56 is compared to the ev5.
> > Still we're talking about a chip that came out in 1996.
>
> Ah yes, I stand corrected. According to Wikipedia, the
From: Paul E. McKenney
> On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
> > Hi James,
> >
> > On 09/04/2014 10:11 PM, James Bottomley wrote:
> > > On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
> > >> +And there are anti-guarantees:
> > >> +
> > >> + (*) These guarantees
From: Paul E. McKenney
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
Hi James,
On 09/04/2014 10:11 PM, James Bottomley wrote:
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
+And there are anti-guarantees:
+
+ (*) These guarantees do not apply to
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected
[ +cc linux-arm ]
Hi David,
On 09/05/2014 04:30 AM, David Laight wrote:
I've seen gcc generate 32bit accesses for 16bit structure members on arm.
It does this because of the more limited range of the offsets for the 16bit
access.
OTOH I don't know if it ever did this for writes - so it may
From: Peter Hurley
[ +cc linux-arm ]
Hi David,
On 09/05/2014 04:30 AM, David Laight wrote:
I've seen gcc generate 32bit accesses for 16bit structure members on arm.
It does this because of the more limited range of the offsets for the 16bit
access.
OTOH I don't know if it ever did
On 09/04/2014 10:08 PM, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected CPUs
were all the
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is a bit ironic because I remember when Digital had a team
working on emulating native x86 apps on Alpha/NT.
Right, because the x86 architecture was obsolete and would never scale...
-hpa
--
To unsubscribe from this list: send the
On 09/05/2014 08:37 AM, David Laight wrote:
From: Peter Hurley
On 09/05/2014 04:30 AM, David Laight wrote:
I've seen gcc generate 32bit accesses for 16bit structure members on arm.
It does this because of the more limited range of the offsets for the 16bit
access.
OTOH I don't know if it
On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're talking about a chip that came out in 1996.
On Fri, Sep 05, 2014 at 11:09:50AM -0700, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no
On 09/05/2014 03:05 PM, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
[cut]
documentation: Record limitations of bitfields and
On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
CPUs without single-byte and double-byte loads and stores place some
interesting requirements on concurrent code. For example (adapted
from Peter
On 09/05/2014 03:52 PM, Peter Zijlstra wrote:
On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
CPUs without single-byte and double-byte loads and stores place some
interesting requirements on concurrent
On Fri, Sep 05, 2014 at 03:24:35PM -0400, Peter Hurley wrote:
On 09/05/2014 03:05 PM, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
[cut]
On Fri, Sep 05, 2014 at 04:01:35PM -0400, Peter Hurley wrote:
So does this patch depends on a patch that removes pre EV56 alpha
support? I'm all for removing that, but I need to see the patch merged
before we can do this.
I'm working on that but Alpha's Kconfig is not quite
On 09/05/2014 03:38 PM, Marc Gauthier wrote:
Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
This commit documents the fact that it is not safe to use bitfields as
shared variables in synchronization
On 09/05/2014 01:12 PM, Peter Zijlstra wrote:
... and I'm wondering if I should _remove_ pre-EV56 configurations or
move the default choice and produce a warning about unsupported Alpha
CPUs instead?
depends BROKEN
or is that deprecated?
Just rip it out, like I did for the i386.
On Fri, Sep 05, 2014 at 04:01:35PM -0400, Peter Hurley wrote:
On 09/05/2014 03:52 PM, Peter Zijlstra wrote:
On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
CPUs without single-byte and double-byte
Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
This commit documents the fact that it is not safe to use bitfields as
shared variables in synchronization algorithms. It also documents that
CPUs must provide
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit message:
It [this commit] documents that CPUs [supported by the Linux kernel]
_must provide_ atomic one-byte and two-byte naturally aligned loads and
stores.
Second, in the body of
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
Second, in the body of the document:
The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these
older CPUs _do not provide_ atomic one-byte and two-byte loads and stores.
Let's be clear here, the pre-EV56 Alpha CPUs do
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
On 09/05/2014 03:38 PM, Marc Gauthier wrote:
Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
This commit documents the fact that it is not
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote:
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit message:
It [this commit] documents that CPUs [supported by the Linux kernel]
_must provide_ atomic one-byte and
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote:
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit message:
It [this commit] documents that CPUs [supported by the Linux kernel]
_must provide_ atomic one-byte and
On Fri, 5 Sep 2014, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote:
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit message:
It [this commit] documents that CPUs [supported by the
On Fri, Sep 05, 2014 at 10:48:34PM +0200, Thomas Gleixner wrote:
On Fri, 5 Sep 2014, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote:
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit
On 09/05/2014 04:39 PM, Michael Cree wrote:
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
Second, in the body of the document:
The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these
older CPUs _do not provide_ atomic one-byte and two-byte loads and stores.
On Fri, Sep 05, 2014 at 05:12:28PM -0400, Peter Hurley wrote:
On 09/05/2014 04:39 PM, Michael Cree wrote:
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
Second, in the body of the document:
The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these
older CPUs
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
> Hi James,
>
> On 09/04/2014 10:11 PM, James Bottomley wrote:
> > On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
> >> +And there are anti-guarantees:
> >> +
> >> + (*) These guarantees do not apply to bitfields, because
Hi James,
On 09/04/2014 10:11 PM, James Bottomley wrote:
> On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
>> +And there are anti-guarantees:
>> +
>> + (*) These guarantees do not apply to bitfields, because compilers often
>> + generate code to modify these using non-atomic
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
> +And there are anti-guarantees:
> +
> + (*) These guarantees do not apply to bitfields, because compilers often
> + generate code to modify these using non-atomic read-modify-write
> + sequences. Do not attempt to use bitfields
On 09/04/2014 05:59 PM, Peter Hurley wrote:
> I have no idea how prevalent the ev56 is compared to the ev5.
> Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected CPUs
were all the 2106x CPUs (EV4, EV45, LCA4, LCA45) plus the
On 09/04/2014 05:59 PM, Peter Hurley wrote:
> I have no idea how prevalent the ev56 is compared to the ev5.
> Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected CPUs
were all the 2106x CPUs (EV4, EV45, LCA4, LCA45) plus the
[ +cc linux-alpha ]
Hi Paul,
On 09/04/2014 08:17 PM, Paul E. McKenney wrote:
> On Thu, Sep 04, 2014 at 03:16:03PM -0700, H. Peter Anvin wrote:
>> On 09/04/2014 12:42 PM, Peter Hurley wrote:
>>>
>>> Or we could give up on the Alpha.
>>>
>>
>> If Alpha is turning into Voyager (kept alive only as a
[ +cc linux-alpha ]
On 09/04/2014 06:14 PM, H. Peter Anvin wrote:
> On 09/04/2014 02:52 AM, Benjamin Herrenschmidt wrote:
>>
>> Yeah correct, alpha and bytes right ? Is there any other ? That's why I
>> suggested int.
>>
>
> Even for Alpha it is only the 21064 AFAIK.
For -mcpu=ev5 (21164) and
On Thu, Sep 04, 2014 at 03:16:03PM -0700, H. Peter Anvin wrote:
> On 09/04/2014 12:42 PM, Peter Hurley wrote:
> >
> > Or we could give up on the Alpha.
> >
>
> If Alpha is turning into Voyager (kept alive only as a museum piece, but
> actively causing problems) then please let's kill it.
Sorry
On 09/04/2014 12:42 PM, Peter Hurley wrote:
>
> Or we could give up on the Alpha.
>
If Alpha is turning into Voyager (kept alive only as a museum piece, but
actively causing problems) then please let's kill it.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe
On 09/04/2014 02:52 AM, Benjamin Herrenschmidt wrote:
>
> Yeah correct, alpha and bytes right ? Is there any other ? That's why I
> suggested int.
>
Even for Alpha it is only the 21064 AFAIK.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On 09/04/2014 12:50 PM, One Thousand Gnomes wrote:
>> Besides updating the documentation, it may make sense to do something
>> arch-specific. Just bumping out storage on arches that don't need it
>> seems wasteful, as does generating bus locks on arches that don't need it.
>> Unfortunately, the
> Besides updating the documentation, it may make sense to do something
> arch-specific. Just bumping out storage on arches that don't need it
> seems wasteful, as does generating bus locks on arches that don't need it.
> Unfortunately, the code churn looks unavoidable.
The arch specific is
On Thu, Sep 04, 2014 at 08:24:12AM -0400, Peter Hurley wrote:
> And I just confirmed with the Alpha cross-compiler that the fields are
> not 'padded out' if volatile either.
They can't be, struct layout is part of the ABI.
Guess you can introduce say atomic_bool and similar typedefs which would
On 09/04/2014 05:09 AM, Jakub Jelinek wrote:
> On Thu, Sep 04, 2014 at 10:57:40AM +0200, Mikael Pettersson wrote:
>> Benjamin Herrenschmidt writes:
>> > On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
>> >
>> > > Apologies for hijacking this thread but I need to extend this discussion
On Thu, 2014-09-04 at 08:43 +, David Laight wrote:
> From: Benjamin Herrenschmidt
> > On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
> >
> > > Apologies for hijacking this thread but I need to extend this discussion
> > > somewhat regarding what a compiler might do with adjacent
On Thu, Sep 04, 2014 at 10:57:40AM +0200, Mikael Pettersson wrote:
> Benjamin Herrenschmidt writes:
> > On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
> >
> > > Apologies for hijacking this thread but I need to extend this discussion
> > > somewhat regarding what a compiler might do
Benjamin Herrenschmidt writes:
> On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
>
> > Apologies for hijacking this thread but I need to extend this discussion
> > somewhat regarding what a compiler might do with adjacent fields in a
> > structure.
> >
> > The tty subsystem
From: Benjamin Herrenschmidt
> On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
>
> > Apologies for hijacking this thread but I need to extend this discussion
> > somewhat regarding what a compiler might do with adjacent fields in a
> > structure.
> >
> > The tty subsystem defines a large
On 09/04/2014 12:50 PM, One Thousand Gnomes wrote:
Besides updating the documentation, it may make sense to do something
arch-specific. Just bumping out storage on arches that don't need it
seems wasteful, as does generating bus locks on arches that don't need it.
Unfortunately, the code churn
On 09/04/2014 02:52 AM, Benjamin Herrenschmidt wrote:
Yeah correct, alpha and bytes right ? Is there any other ? That's why I
suggested int.
Even for Alpha it is only the 21064 AFAIK.
-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On 09/04/2014 12:42 PM, Peter Hurley wrote:
Or we could give up on the Alpha.
If Alpha is turning into Voyager (kept alive only as a museum piece, but
actively causing problems) then please let's kill it.
-hpa
--
To unsubscribe from this list: send the line unsubscribe
On Thu, Sep 04, 2014 at 03:16:03PM -0700, H. Peter Anvin wrote:
On 09/04/2014 12:42 PM, Peter Hurley wrote:
Or we could give up on the Alpha.
If Alpha is turning into Voyager (kept alive only as a museum piece, but
actively causing problems) then please let's kill it.
Sorry for being
[ +cc linux-alpha ]
On 09/04/2014 06:14 PM, H. Peter Anvin wrote:
On 09/04/2014 02:52 AM, Benjamin Herrenschmidt wrote:
Yeah correct, alpha and bytes right ? Is there any other ? That's why I
suggested int.
Even for Alpha it is only the 21064 AFAIK.
For -mcpu=ev5 (21164) and the
[ +cc linux-alpha ]
Hi Paul,
On 09/04/2014 08:17 PM, Paul E. McKenney wrote:
On Thu, Sep 04, 2014 at 03:16:03PM -0700, H. Peter Anvin wrote:
On 09/04/2014 12:42 PM, Peter Hurley wrote:
Or we could give up on the Alpha.
If Alpha is turning into Voyager (kept alive only as a museum piece,
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected CPUs
were all the 2106x CPUs (EV4, EV45, LCA4, LCA45) plus the 21164
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected CPUs
were all the 2106x CPUs (EV4, EV45, LCA4, LCA45) plus the 21164
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
+And there are anti-guarantees:
+
+ (*) These guarantees do not apply to bitfields, because compilers often
+ generate code to modify these using non-atomic read-modify-write
+ sequences. Do not attempt to use bitfields to
Hi James,
On 09/04/2014 10:11 PM, James Bottomley wrote:
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
+And there are anti-guarantees:
+
+ (*) These guarantees do not apply to bitfields, because compilers often
+ generate code to modify these using non-atomic
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
Hi James,
On 09/04/2014 10:11 PM, James Bottomley wrote:
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
+And there are anti-guarantees:
+
+ (*) These guarantees do not apply to bitfields, because compilers often
From: Benjamin Herrenschmidt
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
Apologies for hijacking this thread but I need to extend this discussion
somewhat regarding what a compiler might do with adjacent fields in a
structure.
The tty subsystem defines a large aggregate
Benjamin Herrenschmidt writes:
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
Apologies for hijacking this thread but I need to extend this discussion
somewhat regarding what a compiler might do with adjacent fields in a
structure.
The tty subsystem defines a large
On Thu, Sep 04, 2014 at 10:57:40AM +0200, Mikael Pettersson wrote:
Benjamin Herrenschmidt writes:
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
Apologies for hijacking this thread but I need to extend this discussion
somewhat regarding what a compiler might do with
On Thu, 2014-09-04 at 08:43 +, David Laight wrote:
From: Benjamin Herrenschmidt
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
Apologies for hijacking this thread but I need to extend this discussion
somewhat regarding what a compiler might do with adjacent fields in a
On 09/04/2014 05:09 AM, Jakub Jelinek wrote:
On Thu, Sep 04, 2014 at 10:57:40AM +0200, Mikael Pettersson wrote:
Benjamin Herrenschmidt writes:
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
Apologies for hijacking this thread but I need to extend this discussion
somewhat
On Thu, Sep 04, 2014 at 08:24:12AM -0400, Peter Hurley wrote:
And I just confirmed with the Alpha cross-compiler that the fields are
not 'padded out' if volatile either.
They can't be, struct layout is part of the ABI.
Guess you can introduce say atomic_bool and similar typedefs which would be
Besides updating the documentation, it may make sense to do something
arch-specific. Just bumping out storage on arches that don't need it
seems wasteful, as does generating bus locks on arches that don't need it.
Unfortunately, the code churn looks unavoidable.
The arch specific is pretty
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
> Apologies for hijacking this thread but I need to extend this discussion
> somewhat regarding what a compiler might do with adjacent fields in a
> structure.
>
> The tty subsystem defines a large aggregate structure, struct tty_struct.
>
[ +cc linux-arch, Tony Luck,
On 07/12/2014 02:13 PM, Oleg Nesterov wrote:
> Hello,
>
> I am not sure I should ask here, but since Documentation/memory-barriers.txt
> mentions load/store tearing perhaps my question is not completely off-topic...
>
> I am fighting with mysterious RHEL bug, it
[ +cc linux-arch, Tony Luck,
On 07/12/2014 02:13 PM, Oleg Nesterov wrote:
Hello,
I am not sure I should ask here, but since Documentation/memory-barriers.txt
mentions load/store tearing perhaps my question is not completely off-topic...
I am fighting with mysterious RHEL bug, it can be
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
Apologies for hijacking this thread but I need to extend this discussion
somewhat regarding what a compiler might do with adjacent fields in a
structure.
The tty subsystem defines a large aggregate structure, struct tty_struct.
On 07/15/2014 06:54 AM, Peter Hurley wrote:
>
> Jonathan Corbet wrote a LWN article about this back in 2012:
> http://lwn.net/Articles/478657/
>
> I guess it's fixed in gcc 4.8, but too bad there's not a workaround for
> earlier compilers (akin to -fstrict_volatile_bitfields without requiring
>
On 07/13/2014 06:25 PM, Benjamin Herrenschmidt wrote:
On Sun, 2014-07-13 at 09:15 -0400, Peter Hurley wrote:
I'm not sure I understand your point here, Ben.
Suppose that two different spinlocks are used independently to
protect r-m-w access to adjacent data. In Oleg's example,
suppose
On 07/13/2014 06:25 PM, Benjamin Herrenschmidt wrote:
On Sun, 2014-07-13 at 09:15 -0400, Peter Hurley wrote:
I'm not sure I understand your point here, Ben.
Suppose that two different spinlocks are used independently to
protect r-m-w access to adjacent data. In Oleg's example,
suppose
On 07/15/2014 06:54 AM, Peter Hurley wrote:
Jonathan Corbet wrote a LWN article about this back in 2012:
http://lwn.net/Articles/478657/
I guess it's fixed in gcc 4.8, but too bad there's not a workaround for
earlier compilers (akin to -fstrict_volatile_bitfields without requiring
the
On Sun, 2014-07-13 at 09:15 -0400, Peter Hurley wrote:
>
> I'm not sure I understand your point here, Ben.
>
> Suppose that two different spinlocks are used independently to
> protect r-m-w access to adjacent data. In Oleg's example,
> suppose spinlock 1 is used for access to the bitfield and
>
On 07/12/2014 07:34 PM, Benjamin Herrenschmidt wrote:
On Sat, 2014-07-12 at 22:51 +0200, Oleg Nesterov wrote:
OK, looks like this is compiler bug,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
Thanks to Dan who informed me privately.
So yes, there's is this compiler bug which means a
On 07/13, Benjamin Herrenschmidt wrote:
>
> On Sat, 2014-07-12 at 22:51 +0200, Oleg Nesterov wrote:
> > OK, looks like this is compiler bug,
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
> >
> > Thanks to Dan who informed me privately.
>
> So yes, there's is this compiler bug which
On 07/13, Benjamin Herrenschmidt wrote:
On Sat, 2014-07-12 at 22:51 +0200, Oleg Nesterov wrote:
OK, looks like this is compiler bug,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
Thanks to Dan who informed me privately.
So yes, there's is this compiler bug which means a bitfield
On 07/12/2014 07:34 PM, Benjamin Herrenschmidt wrote:
On Sat, 2014-07-12 at 22:51 +0200, Oleg Nesterov wrote:
OK, looks like this is compiler bug,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
Thanks to Dan who informed me privately.
So yes, there's is this compiler bug which means a
On Sun, 2014-07-13 at 09:15 -0400, Peter Hurley wrote:
I'm not sure I understand your point here, Ben.
Suppose that two different spinlocks are used independently to
protect r-m-w access to adjacent data. In Oleg's example,
suppose spinlock 1 is used for access to the bitfield and
101 - 200 of 206 matches
Mail list logo
