lkml.org 
[lkml]   [2005]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Inconsistent timing results of multithreaded program on an SMP machine.
From
Date

Con Kolivas
<kernel@kolivas.o To: Marcel Zalmanovici/Haifa/IBM@IBMIL
rg> cc: linux-kernel@vger.kernel.org, Muli Ben-Yehuda <mulix@mulix.org>
Subject: Re: Inconsistent timing results of multithreaded program on an SMP
24/11/2005 11:40 machine.












On Thu, 24 Nov 2005 19:33, Marcel Zalmanovici wrote:
> Hi Con,
>
> I've tried the pthread_join theory.
> pthread_join completes very fast, no evidence on it being the perpetrator
> here.
>
> I've ran your ps -... idea in a different term window every ms while the
> test was running. It created a large file so I won't mail it to you, but
> both me and Muli observed that once the thread ends it quickly disappears
> from the ps list.
>
> I've also ran Muli's idea and added gettimeofday calls.
> Here's the altered code and output:
>
> (See attached file: idle.log)(See attached file: sched_test.c)
>
> As you can see, if a thread already finished pthread_join returns in a
> split second.
>
> Any other ideas are welcome :-)

Profile the actual application?

Well, technically, this IS the actual application. Ultimately, I would like
to make some changes to the kernel in order to reduce the cache misses and
maybe improve run time as a consequence.
Having results spread out as much as I get, it would be very difficult, if
not impossible for me to estimate if my algorithm conveyed any real
results.

I have profiled (time ticks and L2 cache misses) the example I've posted
and a few other variations on the example, but haven't seen nothing out of
the ordinary.
Around 98-99% of time and misses are at the inner loop of the example.

Is there anything else I can check with profile that may help me understand
the phenomenon ?

> P.S. - I agree that Lotus isn't ideal for this kind of conversations, but
> that's what IBM is using.

It was tongue in cheek ;) Well that should still not stop you from replying

below the original thread.

Cheers,
Con


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-11-24 11:00    [from the cache]
©2003-2011 Jasper Spaans