When a memcg is created, its dirty limits are set to a copy of the
parent's limits. If the new cgroup is a top level cgroup, then it
inherits from the system parameters (/proc/sys/vm/dirty_*).
Fair enough. I can add more text to Documentation/ describing the
behavior and issue in more detail.
Yes, this is not ideal. I chose not to address this particular issue in
this series to keep the series smaller.
I am not sure if there is interest in hierarchical per-memcg dirty
limits. So I don't think that this is very important to be fixed
immediately. But the fact that it doesn't work is unexpected. It would
be nice if it just worked. I'll look into making it work.
I think it should be a simple matter of enhancing
mem_cgroup_dirty_info() to walk up the hierarchy looking for the cgroup
closest to its dirty limit. The only tricky part is that there are
really two limits (foreground/throttling limit, and a background limit)
that need to be considered when finding the memcg that most deserves
inspection by balance_dirty_pages().
Using the mmap() workload, which is a fault heavy workload...
When memcg is not configured, there is no significant performance
change. Depending on the workload the performance is between 0%..3%
faster. This is likely workload noise.
When memcg is configured, the performance drops between 4% and 8%. Some
of this might be noise, but it is expected that memcg faults will get
slower because there's more code in the fault path.
Here is a test script that shows a situation where memcg dirty limits
are beneficial. The script runs two programs: a dirty page background
antagonist (dd) and an interactive foreground process (tar). If the
scripts argument is false, then both processes are run together in the
root cgroup sharing system-wide dirty memory in classic fashion. If the
script is given a true argument, then a cgroup is used to contain dd
dirty page consumption.
---[start]---
#!/bin/bash
# dirty.sh - dirty limit performance test script
echo use_cgroup: $1
# start antagonist
if $1; then # if using cgroup to contain 'dd'...
mkdir /dev/cgroup/A
echo 400M > /dev/cgroup/A/memory.dirty_limit_in_bytes
(echo $BASHPID > /dev/cgroup/A/tasks; dd if=/dev/zero of=big.file
count=10k bs=1M) &
else
dd if=/dev/zero of=big.file count=10k bs=1M &
fi
sleep 10
time tar -xzf linux-2.6.36.tar.gz
wait
$1 && rmdir /dev/cgroup/A
---[end]---
dirty.sh false : dd 59.7MB/s stddev 7.442%, tar 12.2s stddev 25.720%
# both in root_cgroup
dirty.sh true : dd 55.4MB/s stddev 0.958%, tar 3.8s stddev 0.250%
# tar in root_cgroup, dd in cgroup
The cgroup reserved dirty memory resources for the rest of the system
processes (tar in this case). The tar process had faster and more
predictable performance. memcg dirty ratios might be useful to serve
different task classes (interactive vs batch). A past discussion
touched on this: http://lkml.org/lkml/2010/5/20/136
--
