All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: srostedt@redhat.com
Cc: fweisbec@gmail.com, sparclinux@vger.kernel.org,
	linux-kernel@vger.kernel.org, mingo@elte.hu, acme@redhat.com,
	a.p.zijlstra@chello.nl, paulus@samba.org, rostedt@goodmis.org
Subject: Re: Random scheduler/unaligned accesses crashes with perf lock
Date: Tue, 06 Apr 2010 17:46:35 +0000	[thread overview]
Message-ID: <20100406.104635.210218044.davem@davemloft.net> (raw)
In-Reply-To: <1270561264.2738.8.camel@localhost.localdomain>

From: Steven Rostedt <srostedt@redhat.com>
Date: Tue, 06 Apr 2010 09:41:04 -0400

> It's best to send to my rostedt@goodmis.org account, just like it is
> best to send to your davem@davemloft.net ;-)

Ok then you should, like me, use it in your commits :-)

> OK, so the a 64 bit word still needs 64 bit alignment when storing to a
> data pointer.
> 
> I wonder if we should just have a special copy in this case for the
> events and remove this patch in the ring buffer. That is:
> 
> 	__assign_word(__entry->word, value);
> 
> And have in !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS be:
> 
> 	#define __assgin_word(dest, src)	\
> 		memcpy(&(dest), &(src), sizeof(src));
> 
> This would fix it for all.

Doesn't work, first of all, because if gcc can see the types
it will inline emit aligned loads and stores.

Secondly, the accessors who read in these entries need them to be
aligned too.

> What about removing the logic from the ring buffer and moving it to the
> TRACE_EVENT() macros as I suggested above?

No, that makes no sense, just align the data types properly
instead of making every single access site pay the price.

Just fix the CPP test to handle 32-bit platforms with slow
mis-alignment handling, everything else seems to be working properly
after I fixed the NMI issues on sparc64.

WARNING: multiple messages have this Message-ID (diff)
From: David Miller <davem@davemloft.net>
To: srostedt@redhat.com
Cc: fweisbec@gmail.com, sparclinux@vger.kernel.org,
	linux-kernel@vger.kernel.org, mingo@elte.hu, acme@redhat.com,
	a.p.zijlstra@chello.nl, paulus@samba.org, rostedt@goodmis.org
Subject: Re: Random scheduler/unaligned accesses crashes with perf lock events on sparc 64
Date: Tue, 06 Apr 2010 10:46:35 -0700 (PDT)	[thread overview]
Message-ID: <20100406.104635.210218044.davem@davemloft.net> (raw)
In-Reply-To: <1270561264.2738.8.camel@localhost.localdomain>

From: Steven Rostedt <srostedt@redhat.com>
Date: Tue, 06 Apr 2010 09:41:04 -0400

> It's best to send to my rostedt@goodmis.org account, just like it is
> best to send to your davem@davemloft.net ;-)

Ok then you should, like me, use it in your commits :-)

> OK, so the a 64 bit word still needs 64 bit alignment when storing to a
> data pointer.
> 
> I wonder if we should just have a special copy in this case for the
> events and remove this patch in the ring buffer. That is:
> 
> 	__assign_word(__entry->word, value);
> 
> And have in !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS be:
> 
> 	#define __assgin_word(dest, src)	\
> 		memcpy(&(dest), &(src), sizeof(src));
> 
> This would fix it for all.

Doesn't work, first of all, because if gcc can see the types
it will inline emit aligned loads and stores.

Secondly, the accessors who read in these entries need them to be
aligned too.

> What about removing the logic from the ring buffer and moving it to the
> TRACE_EVENT() macros as I suggested above?

No, that makes no sense, just align the data types properly
instead of making every single access site pay the price.

Just fix the CPP test to handle 32-bit platforms with slow
mis-alignment handling, everything else seems to be working properly
after I fixed the NMI issues on sparc64.

  reply	other threads:[~2010-04-06 17:46 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-04 12:18 Random scheduler/unaligned accesses crashes with perf lock events Frederic Weisbecker
2010-04-04 12:18 ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 Frederic Weisbecker
2010-04-04 12:21 ` Random scheduler/unaligned accesses crashes with perf lock Frederic Weisbecker
2010-04-04 12:21   ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 Frederic Weisbecker
2010-04-05  1:00   ` Random scheduler/unaligned accesses crashes with perf lock David Miller
2010-04-05  1:00     ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 David Miller
2010-04-05  6:57     ` Random scheduler/unaligned accesses crashes with perf lock Frederic Weisbecker
2010-04-05  6:57       ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 Frederic Weisbecker
2010-04-05 19:22       ` Random scheduler/unaligned accesses crashes with perf lock David Miller
2010-04-05 19:22         ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 David Miller
2010-04-05 19:40         ` Random scheduler/unaligned accesses crashes with perf lock Frederic Weisbecker
2010-04-05 19:40           ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 Frederic Weisbecker
2010-04-05 20:46           ` Random scheduler/unaligned accesses crashes with perf lock David Miller
2010-04-05 20:46             ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 David Miller
2010-04-06  2:15           ` Random scheduler/unaligned accesses crashes with perf lock David Miller
2010-04-06  2:15             ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 David Miller
2010-04-06 13:41             ` Random scheduler/unaligned accesses crashes with perf lock Steven Rostedt
2010-04-06 13:41               ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 Steven Rostedt
2010-04-06 17:46               ` David Miller [this message]
2010-04-06 17:46                 ` David Miller
2010-04-06 18:15                 ` Random scheduler/unaligned accesses crashes with perf lock Steven Rostedt
2010-04-06 18:15                   ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 Steven Rostedt
2010-04-06 21:17                   ` Random scheduler/unaligned accesses crashes with perf lock David Miller
2010-04-06 21:17                     ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 David Miller
2010-04-06  9:50           ` Random scheduler/unaligned accesses crashes with perf lock David Miller
2010-04-06  9:50             ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 David Miller
2010-04-06 10:19             ` Random scheduler/unaligned accesses crashes with perf lock Frederic Weisbecker
2010-04-06 10:19               ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 Frederic Weisbecker
2010-04-06 10:28               ` Random scheduler/unaligned accesses crashes with perf lock David Miller
2010-04-06 10:28                 ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 David Miller
2010-04-06 11:12             ` [RFC][PATCH] lockdep: WARN about local_irq_{en,dis}able in NMI Peter Zijlstra
2010-04-06 11:12               ` [RFC][PATCH] lockdep: WARN about local_irq_{en,dis}able in NMI context Peter Zijlstra
2010-04-06 11:13               ` [RFC][PATCH] lockdep: WARN about local_irq_{en,dis}able in NMI David Miller
2010-04-06 11:13                 ` [RFC][PATCH] lockdep: WARN about local_irq_{en,dis}able in NMI context David Miller
2010-04-06 11:20                 ` [RFC][PATCH] lockdep: WARN about local_irq_{en,dis}able in NMI Peter Zijlstra
2010-04-06 11:20                   ` [RFC][PATCH] lockdep: WARN about local_irq_{en,dis}able in NMI context Peter Zijlstra
2010-04-06 11:22                   ` [RFC][PATCH] lockdep: WARN about local_irq_{en,dis}able in NMI David Miller
2010-04-06 11:22                     ` [RFC][PATCH] lockdep: WARN about local_irq_{en,dis}able in NMI context David Miller
2010-04-06 11:38             ` Random scheduler/unaligned accesses crashes with perf lock Frederic Weisbecker
2010-04-06 11:38               ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 Frederic Weisbecker
2010-04-06 11:51               ` Random scheduler/unaligned accesses crashes with perf lock Peter Zijlstra
2010-04-06 11:51                 ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 Peter Zijlstra
2010-04-06 12:54                 ` Random scheduler/unaligned accesses crashes with perf lock Mike Galbraith
2010-04-06 12:54                   ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 Mike Galbraith
2010-04-06 12:57                   ` Random scheduler/unaligned accesses crashes with perf lock Peter Zijlstra
2010-04-06 12:57                     ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 Peter Zijlstra
2010-04-06 18:04             ` Random scheduler/unaligned accesses crashes with perf lock Paul E. McKenney
2010-04-06 18:04               ` Random scheduler/unaligned accesses crashes with perf lock events on sparc 64 Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100406.104635.210218044.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=rostedt@goodmis.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=srostedt@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.