On Wed, 21 Nov 2012 15:01:50 +0000 Mel Gorman <mgorman@xxxxxxx> wrote: > On Tue, Nov 20, 2012 at 10:12:28AM -0800, David Rientjes wrote: > > On Mon, 19 Nov 2012, Anton Vorontsov wrote: > > > > > We try to make userland freeing resources when the system becomes low on > > > memory. Once we're short on memory, sometimes it's better to discard > > > (free) data, rather than let the kernel to drain file caches or even start > > > swapping. > > > > > > > To add another usecase: its possible to modify our version of malloc (or > > any malloc) so that memory that is free()'d can be released back to the > > kernel only when necessary, i.e. when keeping the extra memory around > > starts to have a detremental effect on the system, memcg, or cpuset. When > > there is an abundance of memory available such that allocations need not > > defragment or reclaim memory to be allocated, it can improve performance > > to keep a memory arena from which to allocate from immediately without > > calling the kernel. > > > > A potential third use case is a variation of the first for batch systems. If > it's running low priority tasks and a high priority task starts that > results in memory pressure then the job scheduler may decide to move the > low priority jobs elsewhere (or cancel them entirely). > > A similar use case is monitoring systems running high priority workloads > that should never swap. It can be easily detected if the system starts > swapping but a pressure notification might act as an early warning system > that something is happening on the system that might cause the primary > workload to start swapping. I hope Anton's writing all of this down ;) The proposed API bugs me a bit. It seems simplistic. I need to have a quality think about this. Maybe the result of that think will be to suggest an interface which can be extended in a back-compatible fashion later on, if/when the simplistic nature becomes a problem. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
