YAMAMOTO Takashi wrote: > hi, > >> On Wed, 10 Sep 2008 08:32:15 -0700 >> Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote: >> >>> YAMAMOTO Takashi wrote: >>>> hi, >>>> >>>>> hi, >>>>> >>>>> here's a patch to implement memory.min_usage, >>>>> which controls the minimum memory usage for a cgroup. >>>>> >>>>> it works similarly to mlock; >>>>> global memory reclamation doesn't reclaim memory from >>>>> cgroups whose memory usage is below the value. >>>>> setting it too high is a dangerous operation. >>>>> >>> Looking through the code I am a little worried, what if every cgroup is below >>> minimum value and the system is under memory pressure, do we OOM, while we could >>> have easily reclaimed? > > i'm not sure what you are worring about. can you explain a little more? > under the configuration, OOM is an expected behaviour. > Yes, but an OOM will violate the min_memory right? We promise not to reclaim, but we can OOM. I would rather implement them as watermarks (best effort service, rather than a guarantee). OOMing the system sounds bad, specially if memory can be reclaimed.. No? >>> I would prefer to see some heuristics around such a feature, mostly around the >>> priority that do_try_to_free_pages() to determine how desperate we are for >>> reclaiming memory. >>> >> Taking "priority" of memory reclaim path into account is good. >> >> == >> static unsigned long shrink_inactive_list(unsigned long max_scan, >> struct zone *zone, struct scan_control *sc, >> int priority, int file) >> == >> How about ignore min_usage if "priority < DEF_PRIORITY - 2" ? > > are you suggesting ignoring mlock etc as well in that case? > No.. not at all, we will get an mlock controller as well. > YAMAMOTO Takashi > -- Balbir _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
