lkml.org 
[lkml]   [2007]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4

* Jie Chen <chen@jlab.org> wrote:

>> the moment you saturate the system a bit more, the numbers should
>> improve even with such a ping-pong test.
>
> You are right. If I manually do load balance (bind unrelated processes
> on the other cores), my test code perform as well as it did in the
> kernel 2.6.21.

so right now the results dont seem to be too bad to me - the higher
overhead comes from two threads running on two different cores and
incurring the overhead of cross-core communications. In a true
spread-out workloads that synchronize occasionally you'd get the same
kind of overhead so in fact this behavior is more informative of the
real overhead i guess. In 2.6.21 the two threads would stick on the same
core and produce artificially low latency - which would only be true in
a real spread-out workload if all tasks ran on the same core. (which is
hardly the thing you want on openmp)

In any case, if i misinterpreted your numbers or if you just disagree,
or if have a workload/test that shows worse performance that it
could/should, let me know.

Ingo


\
 
 \ /
  Last update: 2007-12-05 17:51    [W:0.173 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site