pl  |  en

Cache accountability

There was no special mechanism of accountability of the cache in our previous (MT 1.0) offer – we did this manually by adding up PSS of the individual processes. We’ve had no possibility to count the size of the cache that a user occupied.

On the one hand, we were counting things that a user had an influence on. On the other, we didn’t count everything that he was using (ex. some small application, repeatedly calculating MD5 from multi-gigabyte file system that uses very little of PSS/RSS and much more cache, potentially harming other users).

On MT 2.0 we use the memcg (memory control groups) mechanism that is built into the kernel. In this way we always have full information about the cache consumption.

We count up three cache types:

  • RSS (MT 1.0 present) – cache directly used by an application
  • cache (MT 1.0 not present) – cache that isn’t directly used by an application but keeps the data loaded on a disk (to load it only when it’s needed)
  • swap (MT 1.0 not present) – cache that belongs to an application but that can be dumped to the disk to get more cache.

The same application can use more cache on MT 2.0 than on MT 1.0, therefore we’ve doubled the cache comparing to our previous offer. 64-bit operating system also has its influence on the available cache.

We have two different kinds of limits:

  • permanent (based on the chosen package/option)
  • temporary (240 MB, unless there is more in the chosen package/option).

All the processes start in temporary group. After 5 minutes of working we move them to permanent group. The aim is to give more cache to the tasks that quickly end up their lives (ex. Installation tasks).

The kernel is assleep at releasing the cache (that’s good because it eliminates unnecessary I/O moves) so there might be some useless things in memcq but it actually pays off to keep them rather than actively getting rid of them. Hence, the charts may show that the whole cache is taken although there is nothing running at the moment. The cache will be released if it’s necessary.

We rely on the system OOM killer now instead of using our own cache releasing tools (as it was on MT 1.0). It commences when memcq runs out of the cache and it’s hard to release it. Kernel chooses the process that is going to be killed. Usually it’s the most extensive process, but that’s not the rule.