Re: [linux-audio-dev] Re: costs of IPC

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: costs of IPC
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue May 15 2001 - 21:51:24 EEST


abramo - i've just noticed a possibly serious flaw with your test
program.

in real-life, there is (period_duration-cpu_time_for_period) after the
completion of a "proc" cycle during which the processor is free to run
other threads.

in the test, i notice that for the sp case, my processor load on 1 cpu
goes to 100% and stays there for the duration of the test (not
suprising, its running SCHED_RR and never sleeps). this means that you
don't really have enough cache pollution effects from other processes
at all in this case.

i can't test the running-on-UP case here because i have a dual CPU
system, but there is a similar effect there as well. ctx code will own
the CPU as long as it has a thread ready to run, which is essentially
always. therefore no non-ctx thread ever gets to use the CPU, and the
only cache-driven effects you are seeing comes from the data that
*doesn't* fit into the cache. this would explain the slightly
"catastrophic" curve that steve showed - as soon as the pollution data
size exceeds the cache space "dedicated" to ctx, things get *much*
worse. but in a h/w driven system, its quite likely that the effective
cache size would be smaller because other threads would have used it
between periods.

do you see what i'm getting at? does it make sense?

if i'm right, then in a real world scenario (some other process has
used the cache between invocations of proc()), you'd could very well
see dramatic slowdowns with memory footprints notably smaller than
steve's curves suggest.

but i could, as usual, be missing something obvious. you could test
this by using usleep() to put the threads to sleep, measuring the
cycles they actually sleep for, and subtracting that from the
total. you'd also have to ensure a realistic work-load from "other
processes", such as a GUI for each component (and thus the X server)
that wants to update some screen displays.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue May 15 2001 - 22:09:18 EEST