* Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
> On Sat, Aug 04, 2012 at 11:59:10PM +0100, Dr. David Alan Gilbert wrote:
> > A compiler could decide to dereference it using a non-faulting load,
> > do the calculations or whatever on the returned value of the non-faulting
> > load, and
On Sat, Aug 04, 2012 at 11:59:10PM +0100, Dr. David Alan Gilbert wrote:
> * Andrea Arcangeli (aarca...@redhat.com) wrote:
> > On Sat, Aug 04, 2012 at 03:02:45PM -0700, Paul E. McKenney wrote:
> > > OK, I'll bite. ;-)
> >
> > :))
> >
> > > The most sane way for this to happen is with
On Sun, Aug 05, 2012 at 12:47:05AM +0200, Andrea Arcangeli wrote:
> On Sat, Aug 04, 2012 at 03:02:45PM -0700, Paul E. McKenney wrote:
> > OK, I'll bite. ;-)
>
> :))
>
> > The most sane way for this to happen is with feedback-driven techniques
> > involving profiling, similar to what is done for
* Andrea Arcangeli (aarca...@redhat.com) wrote:
> On Sat, Aug 04, 2012 at 03:02:45PM -0700, Paul E. McKenney wrote:
> > OK, I'll bite. ;-)
>
> :))
>
> > The most sane way for this to happen is with feedback-driven techniques
> > involving profiling, similar to what is done for basic-block
On Sat, Aug 04, 2012 at 03:02:45PM -0700, Paul E. McKenney wrote:
> OK, I'll bite. ;-)
:))
> The most sane way for this to happen is with feedback-driven techniques
> involving profiling, similar to what is done for basic-block reordering
> or branch prediction. The idea is that you compile
On Sat, Aug 04, 2012 at 04:37:19PM +0200, Andrea Arcangeli wrote:
> On Tue, Jul 24, 2012 at 02:51:05PM -0700, Hugh Dickins wrote:
> > Since then, I think THP has made the rules more complicated; but I
> > believe Andrea paid a great deal of attention to that kind of issue.
>
> There were many
On Tue, Jul 24, 2012 at 02:51:05PM -0700, Hugh Dickins wrote:
> Since then, I think THP has made the rules more complicated; but I
> believe Andrea paid a great deal of attention to that kind of issue.
There were many issues, one unexpected was
1a5a9906d4e8d1976b701f889d8f35d54b928f25.
Keep in
On Tue, Jul 24, 2012 at 02:51:05PM -0700, Hugh Dickins wrote:
Since then, I think THP has made the rules more complicated; but I
believe Andrea paid a great deal of attention to that kind of issue.
There were many issues, one unexpected was
1a5a9906d4e8d1976b701f889d8f35d54b928f25.
Keep in
On Sat, Aug 04, 2012 at 04:37:19PM +0200, Andrea Arcangeli wrote:
On Tue, Jul 24, 2012 at 02:51:05PM -0700, Hugh Dickins wrote:
Since then, I think THP has made the rules more complicated; but I
believe Andrea paid a great deal of attention to that kind of issue.
There were many issues,
On Sat, Aug 04, 2012 at 03:02:45PM -0700, Paul E. McKenney wrote:
OK, I'll bite. ;-)
:))
The most sane way for this to happen is with feedback-driven techniques
involving profiling, similar to what is done for basic-block reordering
or branch prediction. The idea is that you compile the
* Andrea Arcangeli (aarca...@redhat.com) wrote:
On Sat, Aug 04, 2012 at 03:02:45PM -0700, Paul E. McKenney wrote:
OK, I'll bite. ;-)
:))
The most sane way for this to happen is with feedback-driven techniques
involving profiling, similar to what is done for basic-block reordering
or
On Sun, Aug 05, 2012 at 12:47:05AM +0200, Andrea Arcangeli wrote:
On Sat, Aug 04, 2012 at 03:02:45PM -0700, Paul E. McKenney wrote:
OK, I'll bite. ;-)
:))
The most sane way for this to happen is with feedback-driven techniques
involving profiling, similar to what is done for
On Sat, Aug 04, 2012 at 11:59:10PM +0100, Dr. David Alan Gilbert wrote:
* Andrea Arcangeli (aarca...@redhat.com) wrote:
On Sat, Aug 04, 2012 at 03:02:45PM -0700, Paul E. McKenney wrote:
OK, I'll bite. ;-)
:))
The most sane way for this to happen is with feedback-driven techniques
* Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
On Sat, Aug 04, 2012 at 11:59:10PM +0100, Dr. David Alan Gilbert wrote:
snip
A compiler could decide to dereference it using a non-faulting load,
do the calculations or whatever on the returned value of the non-faulting
load, and then
On Mon, Jul 30, 2012 at 08:21:40PM +0100, Jamie Lokier wrote:
> Paul E. McKenney wrote:
> > > Does some version of gcc, under the options which we insist upon,
> > > make such optimizations on any of the architectures which we support?
> >
> > Pretty much any production-quality compiler will do
Paul E. McKenney wrote:
> > Does some version of gcc, under the options which we insist upon,
> > make such optimizations on any of the architectures which we support?
>
> Pretty much any production-quality compiler will do double-fetch
> and old-value-reuse optimizations, the former especially
Paul E. McKenney wrote:
Does some version of gcc, under the options which we insist upon,
make such optimizations on any of the architectures which we support?
Pretty much any production-quality compiler will do double-fetch
and old-value-reuse optimizations, the former especially on
On Mon, Jul 30, 2012 at 08:21:40PM +0100, Jamie Lokier wrote:
Paul E. McKenney wrote:
Does some version of gcc, under the options which we insist upon,
make such optimizations on any of the architectures which we support?
Pretty much any production-quality compiler will do double-fetch
On Fri, Jul 27, 2012 at 12:22:46PM -0700, Hugh Dickins wrote:
> On Thu, 26 Jul 2012, Peter Zijlstra wrote:
> > On Tue, 2012-07-24 at 14:51 -0700, Hugh Dickins wrote:
> > > I do love the status quo, but an audit would be welcome. When
> > > it comes to patches, personally I tend to prefer
On Thu, 26 Jul 2012, Peter Zijlstra wrote:
> On Tue, 2012-07-24 at 14:51 -0700, Hugh Dickins wrote:
> > I do love the status quo, but an audit would be welcome. When
> > it comes to patches, personally I tend to prefer ACCESS_ONCE() and
> > smp_read_barrier_depends() and accompanying comments to
On Thu, 26 Jul 2012, Peter Zijlstra wrote:
On Tue, 2012-07-24 at 14:51 -0700, Hugh Dickins wrote:
I do love the status quo, but an audit would be welcome. When
it comes to patches, personally I tend to prefer ACCESS_ONCE() and
smp_read_barrier_depends() and accompanying comments to be
On Fri, Jul 27, 2012 at 12:22:46PM -0700, Hugh Dickins wrote:
On Thu, 26 Jul 2012, Peter Zijlstra wrote:
On Tue, 2012-07-24 at 14:51 -0700, Hugh Dickins wrote:
I do love the status quo, but an audit would be welcome. When
it comes to patches, personally I tend to prefer ACCESS_ONCE() and
On Tue, 2012-07-24 at 14:51 -0700, Hugh Dickins wrote:
> I do love the status quo, but an audit would be welcome. When
> it comes to patches, personally I tend to prefer ACCESS_ONCE() and
> smp_read_barrier_depends() and accompanying comments to be hidden away
> in the underlying macros or
On Wed, 2012-07-25 at 15:09 -0700, Hugh Dickins wrote:
> We find out after it hits us, and someone studies the disassembly -
> if we're lucky enough to crash near the origin of the problem.
This is a rather painful way.. see
https://lkml.org/lkml/2009/1/5/555
we were lucky there in that the
On Wed, 2012-07-25 at 15:09 -0700, Hugh Dickins wrote:
We find out after it hits us, and someone studies the disassembly -
if we're lucky enough to crash near the origin of the problem.
This is a rather painful way.. see
https://lkml.org/lkml/2009/1/5/555
we were lucky there in that the
On Tue, 2012-07-24 at 14:51 -0700, Hugh Dickins wrote:
I do love the status quo, but an audit would be welcome. When
it comes to patches, personally I tend to prefer ACCESS_ONCE() and
smp_read_barrier_depends() and accompanying comments to be hidden away
in the underlying macros or inlines
On Wed, Jul 25, 2012 at 03:09:48PM -0700, Hugh Dickins wrote:
> On Wed, 25 Jul 2012, Paul E. McKenney wrote:
> > On Wed, Jul 25, 2012 at 01:26:43PM -0700, Hugh Dickins wrote:
> > > On Wed, 25 Jul 2012, Paul E. McKenney wrote:
> > > > On Tue, Jul 24, 2012 at 02:51:05PM -0700, Hugh Dickins wrote:
>
On Wed, 25 Jul 2012, Paul E. McKenney wrote:
> On Wed, Jul 25, 2012 at 01:26:43PM -0700, Hugh Dickins wrote:
> > On Wed, 25 Jul 2012, Paul E. McKenney wrote:
> > > On Tue, Jul 24, 2012 at 02:51:05PM -0700, Hugh Dickins wrote:
> > > >
> > > > I'm totally unclear whether the kernel ever gets built
On Wed, Jul 25, 2012 at 01:26:43PM -0700, Hugh Dickins wrote:
> On Wed, 25 Jul 2012, Paul E. McKenney wrote:
> > On Tue, Jul 24, 2012 at 02:51:05PM -0700, Hugh Dickins wrote:
> > >
> > > I'm totally unclear whether the kernel ever gets built with these
> > > 'creative' compilers that you refer
On Wed, 25 Jul 2012, Paul E. McKenney wrote:
> On Tue, Jul 24, 2012 at 02:51:05PM -0700, Hugh Dickins wrote:
> >
> > I'm totally unclear whether the kernel ever gets built with these
> > 'creative' compilers that you refer to. Is ACCESS_ONCE() a warning
> > of where some future compiler would be
On Tue, Jul 24, 2012 at 02:51:05PM -0700, Hugh Dickins wrote:
> On Mon, 23 Jul 2012, Peter Zijlstra wrote:
> >
> > While staring at mm/huge_memory.c I found a very under-commented
> > smp_wmb() in __split_huge_page_map(). It turns out that its copied from
> > __{pte,pmd,pud}_alloc() but forgot
On Tue, Jul 24, 2012 at 02:51:05PM -0700, Hugh Dickins wrote:
On Mon, 23 Jul 2012, Peter Zijlstra wrote:
While staring at mm/huge_memory.c I found a very under-commented
smp_wmb() in __split_huge_page_map(). It turns out that its copied from
__{pte,pmd,pud}_alloc() but forgot the useful
On Wed, 25 Jul 2012, Paul E. McKenney wrote:
On Tue, Jul 24, 2012 at 02:51:05PM -0700, Hugh Dickins wrote:
I'm totally unclear whether the kernel ever gets built with these
'creative' compilers that you refer to. Is ACCESS_ONCE() a warning
of where some future compiler would be
On Wed, Jul 25, 2012 at 01:26:43PM -0700, Hugh Dickins wrote:
On Wed, 25 Jul 2012, Paul E. McKenney wrote:
On Tue, Jul 24, 2012 at 02:51:05PM -0700, Hugh Dickins wrote:
I'm totally unclear whether the kernel ever gets built with these
'creative' compilers that you refer to. Is
On Wed, 25 Jul 2012, Paul E. McKenney wrote:
On Wed, Jul 25, 2012 at 01:26:43PM -0700, Hugh Dickins wrote:
On Wed, 25 Jul 2012, Paul E. McKenney wrote:
On Tue, Jul 24, 2012 at 02:51:05PM -0700, Hugh Dickins wrote:
I'm totally unclear whether the kernel ever gets built with these
On Wed, Jul 25, 2012 at 03:09:48PM -0700, Hugh Dickins wrote:
On Wed, 25 Jul 2012, Paul E. McKenney wrote:
On Wed, Jul 25, 2012 at 01:26:43PM -0700, Hugh Dickins wrote:
On Wed, 25 Jul 2012, Paul E. McKenney wrote:
On Tue, Jul 24, 2012 at 02:51:05PM -0700, Hugh Dickins wrote:
On Mon, 23 Jul 2012, Peter Zijlstra wrote:
>
> While staring at mm/huge_memory.c I found a very under-commented
> smp_wmb() in __split_huge_page_map(). It turns out that its copied from
> __{pte,pmd,pud}_alloc() but forgot the useful comment (or a reference
> thereto).
>
> Now, afaict we're not
On Mon, 23 Jul 2012, Peter Zijlstra wrote:
While staring at mm/huge_memory.c I found a very under-commented
smp_wmb() in __split_huge_page_map(). It turns out that its copied from
__{pte,pmd,pud}_alloc() but forgot the useful comment (or a reference
thereto).
Now, afaict we're not good,
On Mon, Jul 23, 2012 at 07:34:30PM +0200, Peter Zijlstra wrote:
>
> While staring at mm/huge_memory.c I found a very under-commented
> smp_wmb() in __split_huge_page_map(). It turns out that its copied from
> __{pte,pmd,pud}_alloc() but forgot the useful comment (or a reference
> thereto).
>
>
While staring at mm/huge_memory.c I found a very under-commented
smp_wmb() in __split_huge_page_map(). It turns out that its copied from
__{pte,pmd,pud}_alloc() but forgot the useful comment (or a reference
thereto).
Now, afaict we're not good, as per that comment. Paul has since
convinced some
While staring at mm/huge_memory.c I found a very under-commented
smp_wmb() in __split_huge_page_map(). It turns out that its copied from
__{pte,pmd,pud}_alloc() but forgot the useful comment (or a reference
thereto).
Now, afaict we're not good, as per that comment. Paul has since
convinced some
On Mon, Jul 23, 2012 at 07:34:30PM +0200, Peter Zijlstra wrote:
While staring at mm/huge_memory.c I found a very under-commented
smp_wmb() in __split_huge_page_map(). It turns out that its copied from
__{pte,pmd,pud}_alloc() but forgot the useful comment (or a reference
thereto).
Now,
42 matches
Mail list logo
