public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <srostedt@redhat.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [RFC 1/2] ftrace porting of ia64
Date: Thu, 18 Dec 2008 15:31:51 +0000	[thread overview]
Message-ID: <1229614311.30177.53.camel@localhost.localdomain> (raw)
In-Reply-To: <1229570238.28616.31.camel@sli10-desk.sh.intel.com>


On Thu, 2008-12-18 at 15:28 +0100, Ingo Molnar wrote:
> * Steven Rostedt <srostedt@redhat.com> wrote:
> 
> > 
> > On Thu, 2008-12-18 at 11:25 +0100, Ingo Molnar wrote:
> > > * Shaohua Li <shaohua.li@intel.com> wrote:
> > > 
> > > > ftrace porting of IA64.
> > > > TBD:
> > > > 1. I don't how to add unwind info to the assemble code, so please
> > > > advise.
> > > > 2. The generic ftrace ring buffer code doesn't handle alignment well.
> > > > With the patch, kernel will report a lot of unalignment. This is still
> > > > under investigation.
> > > 
> > > hm, that's weird - i recently profiled 64-bit x86 for unaligned accesses 
> > > and there didnt seem to be many. In any case, feel free to fix any 
> > > unaligned structure fields by reordering them.
> > 
> > Will x86_64 break if something is aligned by 32 bits?
> 
> No, but there are tools to detect misalignment as they happen. (there are 
> CPU hw counters for access misalignment and kerneltop can profile based on 
> that info :-)
> 
> > The records in the buffer use to be 64 bit aligned. They are now 32 bit 
> > aligned. I wonder if we should make that alignment arch specific.
> 
> No, we should just align them to 64 bits and be done with it.

I originally had it 64 bit aligned, but a lot of people complained about
the wasted space. The minimum record was 8 bytes, but you could have a
12 byte record. This allows for more compact recording.

Hmm, the header is 32 bits. Maybe that's the problem. The data part
starts at the 32bit mark. Maybe it is not the alignment of the record,
but the alignment of where the data starts. If the size is small enough,
it might align to the 32bit boundary.

I'll have to look more into that.

-- Steve



  parent reply	other threads:[~2008-12-18 15:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-18  3:17 [RFC 1/2] ftrace porting of ia64 Shaohua Li
2008-12-18 10:25 ` Ingo Molnar
2008-12-18 14:01 ` Steven Rostedt
2008-12-18 14:28 ` Ingo Molnar
2008-12-18 15:31 ` Steven Rostedt [this message]
2008-12-19  9:03 ` Shaohua Li
2008-12-19  9:09 ` Ingo Molnar

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=1229614311.30177.53.camel@localhost.localdomain \
    --to=srostedt@redhat.com \
    --cc=linux-ia64@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox