Re: [RFC 1/3] /dev/low_mem_notify
From: Pekka Enberg <penberg@kernel.org>
Date: 2012-01-19 11:07:55
Also in:
lkml
On Thu, Jan 19, 2012 at 12:53 PM, [off-list ref] wrote:
From potential user point of view the proposed API has number of lacks which would be nice to have implemented:
On Thu, Jan 19, 2012 at 12:53 PM, [off-list ref] wrote:
From potential user point of view the proposed API has number of lacks which would be nice to have implemented:
1. rename this API from low_mem_pressure to something more related to notification and memory situation in system: memory_pressure, memnotify, memory_level etc. The word "low" is misleading here
The thing is called vmevent: http://git.kernel.org/?p=linux/kernel/git/penberg/linux.git;a=shortlog;h=refs/heads/vmevent/core [penberg@tux ~]$ vi [penberg@tux ~]$ cat email On Thu, Jan 19, 2012 at 12:53 PM, [off-list ref] wrote:
From potential user point of view the proposed API has number of lacks which would be nice to have implemented:
1. rename this API from low_mem_pressure to something more related to notification and memory situation in system: memory_pressure, memnotify, memory_level etc. The word "low" is misleading here
The thing is called vmevent: http://git.kernel.org/?p=linux/kernel/git/penberg/linux.git;a=shortlog;h=refs/heads/vmevent/core I haven't used "low mem" at all in the patches. On Thu, Jan 19, 2012 at 12:53 PM, [off-list ref] wrote:
2. API must use deferred timers to prevent use-time impact. Deferred timer will be triggered only in case HW event or non-deferrable timer, so if device sleeps timer might be skipped and that is what expected for user-space
I'm currently looking at the possibility of hooking VM events to perf which also uses hrtimers. Can't we make hrtimers do the right thing? On Thu, Jan 19, 2012 at 12:53 PM, [off-list ref] wrote:
3. API should be tunable for propagate changes when level is Up or Down, maybe both ways.
Agreed. On Thu, Jan 19, 2012 at 12:53 PM, [off-list ref] wrote:
4. to avoid triggering too much events probably has sense to filter according to amount of change but that is optional. If subscriber set timer to 1s the amount of events should not be very big.
Agreed. On Thu, Jan 19, 2012 at 12:53 PM, [off-list ref] wrote:
5. API must provide interface to request parameters e.g. available swap or free memory just to have some base.
The current ABI already supports that. You can specify which attributes you're interested in and they will be delivered as part of th event. On Thu, Jan 19, 2012 at 12:53 PM, [off-list ref] wrote:
6. I do not understand how work with attributes performed ( ) but it has sense to use mask and fill requested attributes using mask and callback table i.e. if free pages requested - they are reported, otherwise not.
That's how it works now in the git tree. On Thu, Jan 19, 2012 at 12:53 PM, [off-list ref] wrote:
7. would have sense to backport couple of attributes from memnotify.c I can submit couple of patches if some of proposals looks sane for everyone.
Feel free to do that. I'm currently looking at how to support Minchan's non-sampled events. It seems to me integrating with perf would be nice because we could simply use tracepoints for this. Pekka -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>