On Thu 14-05-20 16:21:30, Johannes Weiner wrote:

On Thu, May 14, 2020 at 09:42:46AM +0200, Michal Hocko wrote:

quoted

On Wed 13-05-20 11:36:23, Jakub Kicinski wrote:

quoted

On Wed, 13 May 2020 10:32:49 +0200 Michal Hocko wrote:

quoted

On Tue 12-05-20 10:55:36, Jakub Kicinski wrote:

quoted

On Tue, 12 May 2020 09:26:34 +0200 Michal Hocko wrote:  

quoted

On Mon 11-05-20 15:55:16, Jakub Kicinski wrote:  

quoted

Use swap.high when deciding if swap is full.    

Please be more specific why.  

How about:

    Use swap.high when deciding if swap is full to influence ongoing
    swap reclaim in a best effort manner.  

This is still way too vague. The crux is why should we treat hard and
high swap limit the same for mem_cgroup_swap_full purpose. Please
note that I am not saying this is wrong. I am asking for a more
detailed explanation mostly because I would bet that somebody
stumbles over this sooner or later.

Stumbles in what way?

Reading the code and trying to understand why this particular decision
has been made. Because it might be surprising that the hard and high
limits are treated same here.

I don't quite understand the controversy.

I do not think there is any controversy. All I am asking for is a
clarification because this is non-intuitive.
 

The idea behind "swap full" is that as long as the workload has plenty
of swap space available and it's not changing its memory contents, it
makes sense to generously hold on to copies of data in the swap
device, even after the swapin. A later reclaim cycle can drop the page
without any IO. Trading disk space for IO.

But the only two ways to reclaim a swap slot is when they're faulted
in and the references go away, or by scanning the virtual address space
like swapoff does - which is very expensive (one could argue it's too
expensive even for swapoff, it's often more practical to just reboot).

So at some point in the fill level, we have to start freeing up swap
slots on fault/swapin. Otherwise we could eventually run out of swap
slots while they're filled with copies of data that is also in RAM.

We don't want to OOM a workload because its available swap space is
filled with redundant cache.

Thanks this is a useful summary.
 

That applies to physical swap limits, swap.max, and naturally also to
swap.high which is a limit to implement userspace OOM for swap space
exhaustion.

quoted

quoted

Isn't it expected for the kernel to take reasonable precautions to
avoid hitting limits?

Isn't the throttling itself the precautious? How does the swap cache
and its control via mem_cgroup_swap_full interact here. See? This is
what I am asking to have explained in the changelog.

It sounds like we need better documentation of what vm_swap_full() and
friends are there for. It should have been obvious why swap.high - a
limit on available swap space - hooks into it.

Agreed. The primary source for a confusion is the naming here. Because
vm_swap_full doesn't really try to tell that the swap is full. It merely
tries to tell that it is getting full and so duplicated data should be
dropped.

-- 
Michal Hocko
SUSE Labs