doc: describe memcg swappiness more precisely

doc: describe memcg swappiness more precisely

since fe35004f (mm: avoid swapping out with swappiness==0) memcg reclaim
stopped swapping out anon pages completely when 0 value is used.
Although this is somehow expected it hasn't been done for a really long
time this way and so it is probably better to be explicit about the
effect. Moreover global reclaim swapps out even when swappiness is 0
to prevent from OOM killer.

The original issue (a wrong tasks get killed in a small group and memcg
swappiness=0) has been reported on top of our 3.0 based kernel (with
fe35004f backported).  I have tried to replicate it by the test case
mentioned https://lkml.org/lkml/2012/10/10/223.

As David correctly pointed out (https://lkml.org/lkml/2012/10/10/418) the
significant role played the fact that all the processes in the group have
CAP_SYS_ADMIN but oom_score_adj has the similar effect.  Say there is 2G
of swap space which is 524288 pages.  If you add CAP_SYS_ADMIN bonus then
you have -15728 score for the bias.  This means that all tasks with less
than 60M get the minimum score and it is tasks ordering which determines
who gets killed as a result.

To summarize it.  Users of small groups (relatively to the swap size) with
CAP_SYS_ADMIN tasks resp.  oom_score_adj are affected the most others
might see an unexpected oom_badness calculation.  Whether this is a
workload which is representative, I don't know but I think that it is
worth fixing and pushing to stable as well.

Signed-off-by: Michal Hocko <mhocko@suse.cz>
Cc: David Rientjes <rientjes@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>