From: juntang.fu@windriver.com (Fu Juntang(David))
Subject: [ltt-dev] (forw) [chris.meyers.fsu@gmail.com: Re: ltt channel thread safe?]
Date: Mon, 16 Aug 2010 10:45:17 +0800 [thread overview]
Message-ID: <1281926717.4397.6.camel@david-desktop> (raw)
In-Reply-To: <20100813122418.GA32263@Krystal>
Hi,Mathieu:
> It all looks fine so far. Note that the Linux scheduler can decide to
> schedule your 2 threads on the same CPU. How do you detect that there is
> a "problem": is it that events you are writing from a specific thread
> are missing or that you expect events on CPU 1 and don't have any ?
>
I can monitor which cpu core my threads are running on by the function:
sched_getcpu()
.
the events are missing in other core.
thanks
On Fri, 2010-08-13 at 08:24 -0400, Mathieu Desnoyers wrote:
> * Fu Juntang(David) (juntang.fu at windriver.com) wrote:
> > Hi,Mathieu:
> > Please see my answer inline:
> >
> > On Thu, 2010-08-12 at 09:40 -0400, Mathieu Desnoyers wrote:
> > > * Fu Juntang(David) (juntang.fu at windriver.com) wrote:
> > > > Hi,Mathieu:
> > > > I have found another UST bug in this multi-thread functions:
> > > > in my SMP host(2 cpu cores),I have found that UST can only collect one
> > > > thread trace logs running one core(CPU_1),but can not collect the
> > > > other thread trace logs running another core(CPU_0),is this a known
> > > > bug?
> > > > if you need my debug logs, I can attach it to you.
> > >
> [...]
> > > Can you try putting a printf in
> > >
> > > ust/libust/buffer.c: get_n_cpus() to see how many CPUs the library
> > > detects ?
> > >
> > yes,sure, the output says that it detects 2 cpus
> >
> > > What does your usttrace directory looks like ? (the subdir containing
> > > the ust and metadata files... with ls -al)
> > >
> > total 24
> > drwxr-xr-x 2 david david 4096 2010-08-13 15:30 .
> > drwxr-xr-x 3 david david 4096 2010-08-13 15:30 ..
> > -rw------- 1 david david 4096 2010-08-13 15:30 metadata_0
> > -rw------- 1 david david 4096 2010-08-13 15:30 metadata_1
> > -rw------- 1 david david 4096 2010-08-13 15:30 ust_0
> > -rw------- 1 david david 4096 2010-08-13 15:30 ust_1
> >
>
> It all looks fine so far. Note that the Linux scheduler can decide to
> schedule your 2 threads on the same CPU. How do you detect that there is
> a "problem": is it that events you are writing from a specific thread
> are missing or that you expect events on CPU 1 and don't have any ?
>
> The latter case could be normal.
>
> Thanks,
>
> Mathieu
>
next prev parent reply other threads:[~2010-08-16 2:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-10 21:07 Mathieu Desnoyers
2010-08-10 21:07 ` Mathieu Desnoyers
2010-08-10 21:07 ` Mathieu Desnoyers
2010-08-11 15:39 ` Mathieu Desnoyers
2010-08-12 8:03 ` Fu Juntang(David)
2010-08-12 13:40 ` Mathieu Desnoyers
2010-08-13 7:37 ` Fu Juntang(David)
2010-08-13 12:24 ` Mathieu Desnoyers
2010-08-16 2:45 ` Fu Juntang(David) [this message]
[not found] ` <1282881078.21590.26.camel@david-desktop>
2010-08-27 17:01 ` Mathieu Desnoyers
2010-09-09 6:10 ` Pierre-Marc Fournier
2010-09-09 16:40 ` Mathieu Desnoyers
2010-09-09 16:54 ` David Goulet
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=1281926717.4397.6.camel@david-desktop \
--to=juntang.fu@windriver.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox