* Peter Zijlstra wrote:
> On Thu, Nov 07, 2013 at 09:21:22AM +0100, Ingo Molnar wrote:
> >
> > * Peter Zijlstra wrote:
> >
> > > > Requiring the user of a kernel interface to have a deep knowledge of
> > > > optimizing compilers, barriers, and CPU memory models is just asking
> > > > for
On Thu, Nov 07, 2013 at 09:21:22AM +0100, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > > Requiring the user of a kernel interface to have a deep knowledge of
> > > optimizing compilers, barriers, and CPU memory models is just asking
> > > for trouble.
> >
> > It shouldn't be all that
On Thu, Nov 07, 2013 at 09:21:22AM +0100, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
Requiring the user of a kernel interface to have a deep knowledge of
optimizing compilers, barriers, and CPU memory models is just asking
for trouble.
It shouldn't be all
* Peter Zijlstra pet...@infradead.org wrote:
On Thu, Nov 07, 2013 at 09:21:22AM +0100, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
Requiring the user of a kernel interface to have a deep knowledge of
optimizing compilers, barriers, and CPU memory models is
* Vince Weaver wrote:
> On Thu, 7 Nov 2013, Ingo Molnar wrote:
>
> > I don't want a library that is external and under-tested: for example
> > quite a few of the PAPI breakages were found very late, after a new
> > kernel has been released - that's the big disadvantage of
> > librarization
On Thu, 7 Nov 2013, Ingo Molnar wrote:
> I don't want a library that is external and under-tested: for example
> quite a few of the PAPI breakages were found very late, after a new kernel
> has been released - that's the big disadvantage of librarization and
> decentralization. The
* Peter Zijlstra wrote:
> > Requiring the user of a kernel interface to have a deep knowledge of
> > optimizing compilers, barriers, and CPU memory models is just asking
> > for trouble.
>
> It shouldn't be all that hard to put this in a (lgpl) library others can
> link to -- that way you
* Peter Zijlstra pet...@infradead.org wrote:
Requiring the user of a kernel interface to have a deep knowledge of
optimizing compilers, barriers, and CPU memory models is just asking
for trouble.
It shouldn't be all that hard to put this in a (lgpl) library others can
link to --
On Thu, 7 Nov 2013, Ingo Molnar wrote:
I don't want a library that is external and under-tested: for example
quite a few of the PAPI breakages were found very late, after a new kernel
has been released - that's the big disadvantage of librarization and
decentralization. The decentralized
* Vince Weaver vi...@deater.net wrote:
On Thu, 7 Nov 2013, Ingo Molnar wrote:
I don't want a library that is external and under-tested: for example
quite a few of the PAPI breakages were found very late, after a new
kernel has been released - that's the big disadvantage of
On Wed, Nov 06, 2013 at 12:31:53PM -0500, Vince Weaver wrote:
> On Wed, 6 Nov 2013, Peter Zijlstra wrote:
>
> > On Wed, Nov 06, 2013 at 03:44:56PM +0100, Peter Zijlstra wrote:
> > > long head = ((__atomic long)pc->data_head).load(memory_order_acquire);
> > >
> > > coupled with:
> > >
> > >
On Wed, 6 Nov 2013, Peter Zijlstra wrote:
> On Wed, Nov 06, 2013 at 03:44:56PM +0100, Peter Zijlstra wrote:
> > long head = ((__atomic long)pc->data_head).load(memory_order_acquire);
> >
> > coupled with:
> >
> > ((__atomic long)pc->data_tail).store(tail, memory_order_release);
> >
> > might
On Wed, Nov 06, 2013 at 03:44:56PM +0100, Peter Zijlstra wrote:
> long head = ((__atomic long)pc->data_head).load(memory_order_acquire);
>
> coupled with:
>
> ((__atomic long)pc->data_tail).store(tail, memory_order_release);
>
> might be the 'right' and proper C11 incantations to avoid having
On Wed, Nov 06, 2013 at 04:10:55PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 06, 2013 at 09:55:17AM -0500, Vince Weaver wrote:
> > Having perf in the kernel tree really makes it hard for you guys to keep a
> > clean API/ABI it seems.
>
> Lock free buffers are 'fun'.. The ABI can be described as:
On Wed, Nov 06, 2013 at 09:55:17AM -0500, Vince Weaver wrote:
> Having perf in the kernel tree really makes it hard for you guys to keep a
> clean API/ABI it seems.
Lock free buffers are 'fun'.. The ABI can be described as:
read pc->data_head
// ensure no other reads get before this point
On Wed, 6 Nov 2013, Peter Zijlstra wrote:
> On Wed, Nov 06, 2013 at 03:00:11PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2013 at 08:50:47AM -0500, Vince Weaver wrote:
> >
> > > remember that there are users trying to use this outside of the kernel
> > > where we don't necessarily have
On Wed, Nov 06, 2013 at 03:00:11PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 06, 2013 at 08:50:47AM -0500, Vince Weaver wrote:
> > On Wed, 6 Nov 2013, tip-bot for Peter Zijlstra wrote:
> >
> > > +++ b/tools/perf/util/evlist.h
> > > @@ -177,7 +177,7 @@ int perf_evlist__strerror_open(struct
On Wed, Nov 06, 2013 at 03:00:11PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 06, 2013 at 08:50:47AM -0500, Vince Weaver wrote:
> > On Wed, 6 Nov 2013, tip-bot for Peter Zijlstra wrote:
> >
> > > +++ b/tools/perf/util/evlist.h
> > > @@ -177,7 +177,7 @@ int perf_evlist__strerror_open(struct
On Wed, Nov 06, 2013 at 08:50:47AM -0500, Vince Weaver wrote:
> On Wed, 6 Nov 2013, tip-bot for Peter Zijlstra wrote:
>
> > +++ b/tools/perf/util/evlist.h
> > @@ -177,7 +177,7 @@ int perf_evlist__strerror_open(struct perf_evlist
> > *evlist, int err, char *buf, s
> > static inline unsigned int
On Wed, 6 Nov 2013, tip-bot for Peter Zijlstra wrote:
> Commit-ID: a94d342b9cb09edfe888ea972af0883b6a8d992b
> Gitweb: http://git.kernel.org/tip/a94d342b9cb09edfe888ea972af0883b6a8d992b
> Author: Peter Zijlstra
> AuthorDate: Wed, 30 Oct 2013 11:42:46 +0100
> Committer: Ingo Molnar
>
Commit-ID: a94d342b9cb09edfe888ea972af0883b6a8d992b
Gitweb: http://git.kernel.org/tip/a94d342b9cb09edfe888ea972af0883b6a8d992b
Author: Peter Zijlstra
AuthorDate: Wed, 30 Oct 2013 11:42:46 +0100
Committer: Ingo Molnar
CommitDate: Wed, 6 Nov 2013 12:34:26 +0100
tools/perf: Add required
Commit-ID: a94d342b9cb09edfe888ea972af0883b6a8d992b
Gitweb: http://git.kernel.org/tip/a94d342b9cb09edfe888ea972af0883b6a8d992b
Author: Peter Zijlstra pet...@infradead.org
AuthorDate: Wed, 30 Oct 2013 11:42:46 +0100
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Wed, 6 Nov 2013
On Wed, 6 Nov 2013, tip-bot for Peter Zijlstra wrote:
Commit-ID: a94d342b9cb09edfe888ea972af0883b6a8d992b
Gitweb: http://git.kernel.org/tip/a94d342b9cb09edfe888ea972af0883b6a8d992b
Author: Peter Zijlstra pet...@infradead.org
AuthorDate: Wed, 30 Oct 2013 11:42:46 +0100
Committer:
On Wed, Nov 06, 2013 at 08:50:47AM -0500, Vince Weaver wrote:
On Wed, 6 Nov 2013, tip-bot for Peter Zijlstra wrote:
+++ b/tools/perf/util/evlist.h
@@ -177,7 +177,7 @@ int perf_evlist__strerror_open(struct perf_evlist
*evlist, int err, char *buf, s
static inline unsigned int
On Wed, Nov 06, 2013 at 03:00:11PM +0100, Peter Zijlstra wrote:
On Wed, Nov 06, 2013 at 08:50:47AM -0500, Vince Weaver wrote:
On Wed, 6 Nov 2013, tip-bot for Peter Zijlstra wrote:
+++ b/tools/perf/util/evlist.h
@@ -177,7 +177,7 @@ int perf_evlist__strerror_open(struct perf_evlist
On Wed, Nov 06, 2013 at 03:00:11PM +0100, Peter Zijlstra wrote:
On Wed, Nov 06, 2013 at 08:50:47AM -0500, Vince Weaver wrote:
On Wed, 6 Nov 2013, tip-bot for Peter Zijlstra wrote:
+++ b/tools/perf/util/evlist.h
@@ -177,7 +177,7 @@ int perf_evlist__strerror_open(struct perf_evlist
On Wed, 6 Nov 2013, Peter Zijlstra wrote:
On Wed, Nov 06, 2013 at 03:00:11PM +0100, Peter Zijlstra wrote:
On Wed, Nov 06, 2013 at 08:50:47AM -0500, Vince Weaver wrote:
remember that there are users trying to use this outside of the kernel
where we don't necessarily have access to
On Wed, Nov 06, 2013 at 09:55:17AM -0500, Vince Weaver wrote:
Having perf in the kernel tree really makes it hard for you guys to keep a
clean API/ABI it seems.
Lock free buffers are 'fun'.. The ABI can be described as:
read pc-data_head
// ensure no other reads get before this point and
On Wed, Nov 06, 2013 at 04:10:55PM +0100, Peter Zijlstra wrote:
On Wed, Nov 06, 2013 at 09:55:17AM -0500, Vince Weaver wrote:
Having perf in the kernel tree really makes it hard for you guys to keep a
clean API/ABI it seems.
Lock free buffers are 'fun'.. The ABI can be described as:
On Wed, Nov 06, 2013 at 03:44:56PM +0100, Peter Zijlstra wrote:
long head = ((__atomic long)pc-data_head).load(memory_order_acquire);
coupled with:
((__atomic long)pc-data_tail).store(tail, memory_order_release);
might be the 'right' and proper C11 incantations to avoid having to
touch
On Wed, 6 Nov 2013, Peter Zijlstra wrote:
On Wed, Nov 06, 2013 at 03:44:56PM +0100, Peter Zijlstra wrote:
long head = ((__atomic long)pc-data_head).load(memory_order_acquire);
coupled with:
((__atomic long)pc-data_tail).store(tail, memory_order_release);
might be the 'right' and
On Wed, Nov 06, 2013 at 12:31:53PM -0500, Vince Weaver wrote:
On Wed, 6 Nov 2013, Peter Zijlstra wrote:
On Wed, Nov 06, 2013 at 03:44:56PM +0100, Peter Zijlstra wrote:
long head = ((__atomic long)pc-data_head).load(memory_order_acquire);
coupled with:
((__atomic
32 matches
Mail list logo
