On Thu, Dec 17, 2015 at 11:46:27AM +0900, Kamezawa Hiroyuki wrote:
> On 2015/12/16 20:09, Johannes Weiner wrote:
> >On Wed, Dec 16, 2015 at 12:18:30PM +0900, Kamezawa Hiroyuki wrote:
> >>  - swap-full notification via vmpressure or something mechanism.
> >
> >Why?
> >
> 
> I think it's a sign of unhealthy condition, starting file cache drop rate to 
> rise.
> But I forgot that there are resource threshold notifier already. Does the 
> notifier work
> for swap.usage ?

That will be reflected in vmpressure or other distress mechanisms. I'm
not convinced "ran out of swap space" needs special casing in any way.

> >>  - force swap-in at reducing swap.limit
> >
> >Why?
> >
> If full, swap.limit cannot be reduced even if there are available memory in a 
> cgroup.
> Another cgroup cannot make use of the swap resource while it's occupied by 
> other cgroup.
> The job scheduler should have a chance to fix the situation.

I don't see why swap space allowance would need to be as dynamically
adjustable as the memory allowance. There is usually no need to be as
tight with swap space as with memory, and the performance penalty of
swapping, even with flash drives, is high enough that swap space acts
as an overflow vessel rather than be part of the regularly backing of
the anonymous/shmem working set. It really is NOT obvious that swap
space would need to be adjusted on the fly, and that it's important
that reducing the limit will be reflected in consumption right away.

We shouldn't be adding hundreds of lines of likely terrible heuristics
code* on speculation that somebody MIGHT find this useful in real life.
We should wait until we are presented with a real usecase that applies
to a whole class of users, and then see what the true requirements are.

* If a group has 200M swapped out and the swap limit is reduced by 10M
below the current consumption, which pages would you swap in? There is
no LRU list for swap space.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to