From: <leonid.moiseichuk@nokia.com>
To: <penberg@kernel.org>
Cc: <rhod@redhat.com>, <riel@redhat.com>, <minchan@kernel.org>,
<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
<kamezawa.hiroyu@jp.fujitsu.com>, <mel@csn.ul.ie>,
<rientjes@google.com>, <kosaki.motohiro@gmail.com>,
<hannes@cmpxchg.org>, <mtosatti@redhat.com>,
<akpm@linux-foundation.org>, <kosaki.motohiro@jp.fujitsu.com>
Subject: RE: [RFC 1/3] /dev/low_mem_notify
Date: Thu, 19 Jan 2012 11:54:58 +0000 [thread overview]
Message-ID: <84FF21A720B0874AA94B46D76DB9826904559D9B@008-AM1MPN1-003.mgdnok.nokia.com> (raw)
In-Reply-To: <CAOJsxLHd5dCvBwV5gsraFZXh86wq7tg7uLLnevN8Pp_jGiOBbw@mail.gmail.com>
> -----Original Message-----
> From: penberg@gmail.com [mailto:penberg@gmail.com] On Behalf Of ext
> Pekka Enberg
> Sent: 19 January, 2012 13:08
...
> > 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:
Yes, I see it. But I was a bit confused with vmnotify_fops and was sure it is mapped through dev. Now it anonymous inode.
>
> On Thu, Jan 19, 2012 at 12:53 PM, <leonid.moiseichuk@nokia.com> 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?
I had no answer for this question. According to hrtimer_cpu_notify the cpu state is tracked but timer may set HW event to wake up.
In this case use-time will be affected due to you will have too much HW events and reasons to wakeup.
At least powertop reports hrtimers in relation to <kernel core> as an activities sources.
>
> On Thu, Jan 19, 2012 at 12:53 PM, <leonid.moiseichuk@nokia.com> 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, <leonid.moiseichuk@nokia.com> 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, <leonid.moiseichuk@nokia.com> 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.
But you have in vmnotify.h suspicious free_pages_threshold field.
>
> On Thu, Jan 19, 2012 at 12:53 PM, <leonid.moiseichuk@nokia.com> 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.
Vmnotify.c has vmnotify_watch_event which collects fixed set of parameters.
> 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.
If tracepoints not jeopardize use time has sense to do it.
>
> Pekka
next prev parent reply other threads:[~2012-01-19 11:55 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-17 8:13 [RFC 0/3] low memory notify Minchan Kim
2012-01-17 8:13 ` [RFC 1/3] /dev/low_mem_notify Minchan Kim
2012-01-17 9:27 ` Pekka Enberg
2012-01-17 16:35 ` Rik van Riel
2012-01-17 18:51 ` Pekka Enberg
2012-01-17 19:30 ` Rik van Riel
2012-01-17 19:49 ` Pekka Enberg
2012-01-17 19:54 ` Pekka Enberg
2012-01-17 19:57 ` Pekka Enberg
2012-01-17 23:20 ` Minchan Kim
2012-01-18 7:16 ` Pekka Enberg
2012-01-18 7:49 ` Minchan Kim
2012-01-18 9:06 ` leonid.moiseichuk
2012-01-18 9:15 ` Pekka Enberg
2012-01-18 9:41 ` leonid.moiseichuk
2012-01-18 10:40 ` Pekka Enberg
2012-01-18 10:44 ` leonid.moiseichuk
2012-01-18 23:34 ` Ronen Hod
2012-01-19 7:25 ` Pekka Enberg
2012-01-19 9:05 ` Ronen Hod
2012-01-19 9:10 ` Pekka Enberg
2012-01-19 9:20 ` Ronen Hod
2012-01-19 10:53 ` leonid.moiseichuk
2012-01-19 11:07 ` Pekka Enberg
2012-01-19 11:54 ` leonid.moiseichuk [this message]
2012-01-19 11:59 ` Pekka Enberg
2012-01-19 12:06 ` Pekka Enberg
2012-01-24 15:38 ` Marcelo Tosatti
2012-01-24 16:08 ` Ronen Hod
2012-01-24 18:10 ` Marcelo Tosatti
2012-01-25 8:52 ` Ronen Hod
2012-01-25 10:12 ` Marcelo Tosatti
2012-01-25 10:48 ` Ronen Hod
2012-01-26 16:17 ` Marcelo Tosatti
2012-01-24 16:10 ` Pekka Enberg
2012-01-24 18:29 ` Marcelo Tosatti
2012-01-25 8:19 ` leonid.moiseichuk
2012-01-19 7:34 ` Pekka Enberg
2012-01-24 16:22 ` Arnd Bergmann
2012-01-18 14:30 ` Rik van Riel
2012-01-18 15:29 ` Pekka Enberg
2012-01-24 15:40 ` Marcelo Tosatti
2012-01-24 16:01 ` Pekka Enberg
2012-01-24 16:25 ` Arnd Bergmann
2012-01-24 18:32 ` Marcelo Tosatti
2012-01-24 21:57 ` Jonathan Corbet
2012-01-17 9:45 ` Pekka Enberg
2012-01-17 8:13 ` [RFC 2/3] vmscan hook Minchan Kim
2012-01-17 8:39 ` KAMEZAWA Hiroyuki
2012-01-17 9:13 ` Minchan Kim
2012-01-17 10:05 ` KAMEZAWA Hiroyuki
2012-01-17 23:08 ` Minchan Kim
2012-01-18 0:18 ` KAMEZAWA Hiroyuki
2012-01-18 14:17 ` Rik van Riel
2012-01-19 2:25 ` KAMEZAWA Hiroyuki
2012-01-19 14:42 ` Rik van Riel
2012-01-20 0:24 ` KAMEZAWA Hiroyuki
2012-01-17 8:13 ` [RFC 3/3] test program Minchan Kim
2012-01-17 14:38 ` [RFC 0/3] low memory notify Colin Walters
2012-01-17 15:04 ` Pekka Enberg
2012-01-17 16:44 ` Rik van Riel
2012-01-17 17:16 ` Olof Johansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84FF21A720B0874AA94B46D76DB9826904559D9B@008-AM1MPN1-003.mgdnok.nokia.com \
--to=leonid.moiseichuk@nokia.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@gmail.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=minchan@kernel.org \
--cc=mtosatti@redhat.com \
--cc=penberg@kernel.org \
--cc=rhod@redhat.com \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).