:-) Please see my response below
Yes, but here's the overall picture of what is happening
1. The system administrator setup a memory container to contain
a group of applications.
2. The administrator tried to swapoff one/a group of swap files/
devices
3. Operation 2, failed due to a container being above it's limit.
Which implies that at some point a container went over it's
limit and some of it's pages were swapped out
During swapoff, we try to account for pages coming back into the
container, our charging routine does try to reclaim pages,
which in turn implies -- it will use another swap device or
reclaim page cache, if both fails, we return -ENOMEM.
Given that the system administrator has setup the container and
the swap devices, I feel that he is in better control of what
to do with the system when swapoff fails.
In the future we plan to implement per container swap (a feature
desired by several people), assuming that administrators use
per container swap in the future, failing on limit sounds
like the right way to go forward.
Yes, precisely my point, the administrator is the best person
to decide how to assign memory to containers. Would it help
to add a container tunable that says, it's ok to go overlimit
with this container during a swapoff.
The problem with that approach is that applications will fail
in the middle of their task. They will never get a chance
to run at all, they will always get killed in the middle.
We want to be able to reclaim pages from the container and
let the application continue.
Tasks failing on limit does not sound good unless we are out
of all backup memory (slow storage). We still let the application
run, although slowly.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
