Hello Yaniv.
I don't do mock. And if I run everything in RAM (whether directly under
/dev/shm/<somewhere> or in a zram disk), I honestly don't
need the Linux
system cache.
>
> Besides the possible difference in disk speeds I think the second factor
> is this Linux fs cache that basically create an analog of RAM disk on the
> fly.
>
Well, theoretically, if you have enough RAM and you keep re-running, many
of the data is indeed going to be cached. I'd argue that it's a better use
of RAM to just run it there.
Ok then I guess we traced down the reason. I did not do any tests to
confirm this yet but I believe the "mock" is causing this effect. On our
side we use mock that is at the moment essential part of the standard CI
offering. Mock utilizes file system cache of the chroots and those cashes
are shared between runs that along with Linux fs cache means that they are
probably already were identified to be good candidates for RAM fs cache and
put there.
So since mock has own cache it should be trivial for Linux to effectively
identify them and put into RAM and this benefits all runs that use mock. If
we remove the mock than it is completely different.
Anton.
--
Anton Marchukov
Senior Software Engineer - RHEV CI - Red Hat