Comment 457 for bug 620074

I'm wondering. Isn't bad reponsiveness equals starvation of processes in the
cpu schedueler? In that case it would be better to meassure the amount of cpu-
cycles it is possible to burn during pekmop1024's procedure.

I have tried to just dd a 8 Gb file, and it gives me stalls in the gui, but it
is because of stat64-calls in the application. Under normal circumstances the
file that is stat'ed is cached. But during high thoughput the cache is filled up
with other data. So the stat64-call have to read from the disk which will the
compete my dd. Running glxgears alongside the dd show a constant fps during to
whole dd.

I have followed this thread a long time and I do not remember anyone
mensioning that a single high thoughput application renders the cache useless
to other applications.

Is it possible to avoid filling the cahce with data that is written ?