Subject: Re: [linux-audio-dev] Re: costs of IPC
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed May 16 2001 - 01:00:48 EEST
>Just boot it with "nosmp" parameter.
thanks. i didn't know about that. it might be very useful.
>If memory footprint threshold become smaller the difference between sp
>and mp decrease. I've just verified this effect with attached ctx, if
>you increase worker area size you'll note too.
hmm. i don't understand how that version tests the point i was
making.
when i look at steve's graphs, the main feature i see is that
in all but one case, the mp performance drops much more significantly
than the sp performance once some kind of memory footprint goes above
a certain size. What I see is:
on a dual CPU system, up to about 100kB of shared memory footprint,
the mp and sp designs function equivalently, with about an extra
4-5% (?) for the mp design.
but in the dual CPU case with about 150Kb of shared memory footprint,
the sp design is using about 35% of the CPU cycles available to
process a period's worth of data, while the mp design is using about
65%. there is a "take off point" at about 100kB. beyond that, the sp
design degrades linearly, the mp design appears to degrade
exponentially.
the value of that "takeoff point" is likely to be affected by other
processes' threads using the cache. if the presence of other runnable
threads reduces that threshold into the "likely range" for the system
we're talking about, then the steep drop in performance for the mp
design becomes quite an issue.
and note: the curves are much more dramatically separated in the
"worker pollution" case.
i am also intrigued by the difference in the UP and SMP curves.
>Here the problem is that "realistic work-load" is hard to define because
>it's related to its memory footprint. Also consider that I don't think
>that the GUI would run every period. And consider that usleep can't
>sleep in not busy loop for less than a jiffie.
right, i agree entirely. the problem is that when X and/or an X client thread
*is* ready to run, you might get substantial cache pollution between
periods ... see below.
>I think that we might consider one worker as the gui (at least on UP).
>GUI effect is surely less than that (if I'm not wrong average cache
>pollution effect can be measured in cache lines/time units and then
>although GUI may have a greater footprint its run frequency is lower).
ah, OK, well I see one point of agreement here. if a GUI stomps on the
entire cache, neither the sp design nor the mp design is immune from
this effect, so we just have to live with it. if the mp design has its
thread running in SCHED_RR, then there are no external cache effects
until all the workers are done executing, so there is no extra
overhead other than the builtin 4-5% that the graphs already show.
--p
This archive was generated by hypermail 2b28 : Wed May 16 2001 - 01:13:51 EEST