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/
