Re: Inconsistent timing results of multithreaded program on an SMP machine.

[Marcel Zalmanovici <MARCEL@il.ibm.com>]

                      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/