On Tue, 2007-12-11 at 17:11 -0500, Jie Chen wrote:
> Ingo Molnar wrote:
> > * Jie Chen <[EMAIL PROTECTED]> wrote:
> >
> >> The following is pthread_sync output for 2.6.21.7-cfs-v24 #1 SMP
> >> kernel.
> >
> >> 2 threads:
> >
> >> PARALLEL time = 11.106580 microseconds +/- 0.002460
> >> P
Ingo Molnar wrote:
* Jie Chen <[EMAIL PROTECTED]> wrote:
The following is pthread_sync output for 2.6.21.7-cfs-v24 #1 SMP
kernel.
2 threads:
PARALLEL time = 11.106580 microseconds +/- 0.002460
PARALLEL overhead =0.617590 microseconds +/- 0.003409
Output for Kernel 2.6.24-rc4
* Jie Chen <[EMAIL PROTECTED]> wrote:
> The following is pthread_sync output for 2.6.21.7-cfs-v24 #1 SMP
> kernel.
> 2 threads:
> PARALLEL time = 11.106580 microseconds +/- 0.002460
> PARALLEL overhead =0.617590 microseconds +/- 0.003409
> Output for Kernel 2.6.24-rc4 #1 SMP
> PARA
Ingo Molnar wrote:
* Jie Chen <[EMAIL PROTECTED]> wrote:
Hi, Ingo:
I guess it is a good news. I did patch 2.6.21.7 kernel using your cfs
patch. The results of pthread_sync is the same as the non-patched
2.6.21 kernel. This means the performance of is not related to the
scheduler. As for ove
* Jie Chen <[EMAIL PROTECTED]> wrote:
> Hi, Ingo:
>
> I guess it is a good news. I did patch 2.6.21.7 kernel using your cfs
> patch. The results of pthread_sync is the same as the non-patched
> 2.6.21 kernel. This means the performance of is not related to the
> scheduler. As for overhead of t
Ingo Molnar wrote:
* Jie Chen <[EMAIL PROTECTED]> wrote:
and then you use this in the measurement loop:
for (k=0; k<=OUTERREPS; k++){
start = getclock();
for (j=0; jthe problem is, this does not take the overhead of gettimeofday into
account - which overhead can easily reach 10
* Jie Chen <[EMAIL PROTECTED]> wrote:
>> and then you use this in the measurement loop:
>>
>>for (k=0; k<=OUTERREPS; k++){
>> start = getclock();
>> for (j=0; j> #ifdef _QMT_PUBLIC
>>delay((void *)0, 0);
>> #else
>>delay(0, 0, 0, (void *)0);
>> #endif
>> }
>
Ingo Molnar wrote:
* Jie Chen <[EMAIL PROTECTED]> wrote:
I did patch the header file and recompiled the kernel. I observed no
difference (two threads overhead stays too high). Thank you.
ok, i think i found it. You do this in your qmt/pthread_sync.c
test-code:
double get_time_of_day_()
{
* Jie Chen <[EMAIL PROTECTED]> wrote:
> I did patch the header file and recompiled the kernel. I observed no
> difference (two threads overhead stays too high). Thank you.
ok, i think i found it. You do this in your qmt/pthread_sync.c
test-code:
double get_time_of_day_()
{
...
err = get
Ingo Molnar wrote:
* Jie Chen <[EMAIL PROTECTED]> wrote:
not "BARRIER time". I've re-read the discussion and found no hint
about how to build and run a barrier test. Either i missed it or it's
so obvious to you that you didnt mention it :-)
Ingo
Hi, Ingo:
Did you do configure --ena
* Jie Chen <[EMAIL PROTECTED]> wrote:
>> not "BARRIER time". I've re-read the discussion and found no hint
>> about how to build and run a barrier test. Either i missed it or it's
>> so obvious to you that you didnt mention it :-)
>>
>> Ingo
>
> Hi, Ingo:
>
> Did you do configure --enable-
Ingo Molnar wrote:
* Jie Chen <[EMAIL PROTECTED]> wrote:
sorry to be dense, but could you give me instructions how i could
remove the affinity mask and test the "barrier overhead" myself? I
have built "pthread_sync" and it outputs numbers for me - which one
would be the barrier overhead: Refe
On Wed, 2007-11-21 at 15:34 -0500, Jie Chen wrote:
> It is clearly that the synchronization overhead increases as the number
> of threads increases in the kernel 2.6.21. But the synchronization
> overhead actually decreases as the number of threads increases in the
> kernel 2.6.23.8 (We observ
* Jie Chen <[EMAIL PROTECTED]> wrote:
>> sorry to be dense, but could you give me instructions how i could
>> remove the affinity mask and test the "barrier overhead" myself? I
>> have built "pthread_sync" and it outputs numbers for me - which one
>> would be the barrier overhead: Reference_ti
Peter Zijlstra wrote:
On Wed, 2007-11-21 at 15:34 -0500, Jie Chen wrote:
It is clearly that the synchronization overhead increases as the number
of threads increases in the kernel 2.6.21. But the synchronization
overhead actually decreases as the number of threads increases in the
kernel 2.6.
Ingo Molnar wrote:
* Jie Chen <[EMAIL PROTECTED]> wrote:
I just disabled the affinity mask and reran the test. There were no
significant changes for two threads (barrier overhead is around 9
microseconds). As for 8 threads, the barrier overhead actually drops a
little, which is good. Let me k
* Jie Chen <[EMAIL PROTECTED]> wrote:
> I just disabled the affinity mask and reran the test. There were no
> significant changes for two threads (barrier overhead is around 9
> microseconds). As for 8 threads, the barrier overhead actually drops a
> little, which is good. Let me know whether
Ingo Molnar wrote:
* Jie Chen <[EMAIL PROTECTED]> wrote:
Since I am using affinity flag to bind each thread to a different
core, the synchronization overhead should increases as the number of
cores/threads increases. But what we observed in the new kernel is the
opposite. The barrier overhead
* Jie Chen <[EMAIL PROTECTED]> wrote:
> Since I am using affinity flag to bind each thread to a different
> core, the synchronization overhead should increases as the number of
> cores/threads increases. But what we observed in the new kernel is the
> opposite. The barrier overhead of two thre
Ingo Molnar wrote:
* Jie Chen <[EMAIL PROTECTED]> 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
* Jie Chen <[EMAIL PROTECTED]> 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
Ingo Molnar a écrit :
* Eric Dumazet <[EMAIL PROTECTED]> wrote:
$ gcc -O2 -o burner burner.c
$ ./burner
Time to perform the unit of work on one thread is 0.040328 s
Time to perform the unit of work on 2 threads is 0.040221 s
ok, but this actually suggests that scheduling is fine for this,
co
* Eric Dumazet <[EMAIL PROTECTED]> wrote:
> $ gcc -O2 -o burner burner.c
> $ ./burner
> Time to perform the unit of work on one thread is 0.040328 s
> Time to perform the unit of work on 2 threads is 0.040221 s
ok, but this actually suggests that scheduling is fine for this,
correct?
I
Ingo Molnar wrote:
* Jie Chen <[EMAIL PROTECTED]> wrote:
I just ran the same test on two 2.6.24-rc4 kernels: one with
CONFIG_FAIR_GROUP_SCHED on and the other with CONFIG_FAIR_GROUP_SCHED
off. The odd behavior I described in my previous e-mails were still
there for both kernels. Let me know I
Ingo Molnar a écrit :
* Jie Chen <[EMAIL PROTECTED]> wrote:
I just ran the same test on two 2.6.24-rc4 kernels: one with
CONFIG_FAIR_GROUP_SCHED on and the other with CONFIG_FAIR_GROUP_SCHED
off. The odd behavior I described in my previous e-mails were still
there for both kernels. Let me kno
* Jie Chen <[EMAIL PROTECTED]> wrote:
> I just ran the same test on two 2.6.24-rc4 kernels: one with
> CONFIG_FAIR_GROUP_SCHED on and the other with CONFIG_FAIR_GROUP_SCHED
> off. The odd behavior I described in my previous e-mails were still
> there for both kernels. Let me know If I can be a
Ingo Molnar wrote:
* Jie Chen <[EMAIL PROTECTED]> wrote:
Simon Holm Th??gersen wrote:
ons, 21 11 2007 kl. 20:52 -0500, skrev Jie Chen:
There is a backport of the CFS scheduler to 2.6.21, see
http://lkml.org/lkml/2007/11/19/127
Hi, Simon:
I will try that after the thanksgiving holiday to fin
Ingo Molnar wrote:
* Jie Chen <[EMAIL PROTECTED]> wrote:
Simon Holm Th??gersen wrote:
ons, 21 11 2007 kl. 20:52 -0500, skrev Jie Chen:
There is a backport of the CFS scheduler to 2.6.21, see
http://lkml.org/lkml/2007/11/19/127
Hi, Simon:
I will try that after the thanksgiving holiday to fin
* Jie Chen <[EMAIL PROTECTED]> wrote:
> Simon Holm Th??gersen wrote:
>> ons, 21 11 2007 kl. 20:52 -0500, skrev Jie Chen:
>
>> There is a backport of the CFS scheduler to 2.6.21, see
>> http://lkml.org/lkml/2007/11/19/127
>>
> Hi, Simon:
>
> I will try that after the thanksgiving holiday to find o
On Wed, Nov 21, 2007 at 09:58:10PM -0500, Jie Chen wrote:
> Simon Holm Th??gersen wrote:
> >ons, 21 11 2007 kl. 20:52 -0500, skrev Jie Chen:
>
> >There is a backport of the CFS scheduler to 2.6.21, see
> >http://lkml.org/lkml/2007/11/19/127
> >
> Hi, Simon:
>
> I will try that after the thanksgiv
Simon Holm Thøgersen wrote:
ons, 21 11 2007 kl. 20:52 -0500, skrev Jie Chen:
There is a backport of the CFS scheduler to 2.6.21, see
http://lkml.org/lkml/2007/11/19/127
Hi, Simon:
I will try that after the thanksgiving holiday to find out whether the
odd behavior will show up using 2.6.21
ons, 21 11 2007 kl. 20:52 -0500, skrev Jie Chen:
> Eric Dumazet wrote:
> > Jie Chen a écrit :
> >> Hi, there:
> >>
> >> We have a simple pthread program that measures the synchronization
> >> overheads for various synchronization mechanisms such as spin locks,
> >> barriers (the barrier is i
Eric Dumazet wrote:
Jie Chen a écrit :
Hi, there:
We have a simple pthread program that measures the synchronization
overheads for various synchronization mechanisms such as spin locks,
barriers (the barrier is implemented using queue-based barrier
algorithm) and so on. We have dual quad
Jie Chen a écrit :
Hi, there:
We have a simple pthread program that measures the synchronization
overheads for various synchronization mechanisms such as spin locks,
barriers (the barrier is implemented using queue-based barrier
algorithm) and so on. We have dual quad-core AMD opterons (b
Hi, there:
We have a simple pthread program that measures the synchronization
overheads for various synchronization mechanisms such as spin locks,
barriers (the barrier is implemented using queue-based barrier
algorithm) and so on. We have dual quad-core AMD opterons (barcelona)
clusters
35 matches
Mail list logo
