From: Anton Vorontsov <cbouatmailru@gmail.com>
To: Pekka Enberg <penberg@kernel.org>
Cc: Minchan Kim <minchan@kernel.org>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>,
Leonid Moiseichuk <leonid.moiseichuk@nokia.com>
Subject: Re: vmevent: question?
Date: Mon, 30 Apr 2012 00:54:18 -0700 [thread overview]
Message-ID: <20120430075417.GA8438@lizard> (raw)
In-Reply-To: <CAOJsxLE3A3b5HSrRm0NVCBmzv7AAs-RWEiZC1BL=se309+=WTA@mail.gmail.com>
Hello Pekka,
On Mon, Apr 30, 2012 at 10:35:02AM +0300, Pekka Enberg wrote:
> > vmevent_smaple gathers all registered values to report to user if vmevent match.
> > But the time gap between vmevent match check and vmevent_sample_attr could make error
> > so user could confuse.
> >
> > Q 1. Why do we report _all_ registered vmstat value?
> > In my opinion, it's okay just to report _a_ value vmevent_match happens.
>
> It makes the userspace side simpler for "lowmem notification" use
> case. I'm open to changing the ABI if it doesn't make the userspace
> side too complex.
Yep. Actually, I'd like to add something like 'file_pages - shmem'
attribute, and reporting both (i.e. this new attr and free_pages)
values at the same time (even if just one crossed the threshold).
Reporting all the values would help userspace logic (so it won't
need to read /proc again).
> > Q 4. Do you have any plan for this patchset to merge into mainline?
>
> Yes, I'm interested in pushing it forward if we can show that the ABI
> makes sense, is stable and generic enough, and fixes real world
> problems.
It seems to be a pretty nice driver. Speaking of ABI, the only thing
I personally dislike is VMEVENT_CONFIG_MAX_ATTRS (i.e. fixed-size
array in vmevent_config)... but I guess it's pretty easy to make
it variable-sized array... was there any particular reason to make
the _MAX thing?
Thanks!
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
WARNING: multiple messages have this Message-ID (diff)
From: Anton Vorontsov <cbouatmailru@gmail.com>
To: Pekka Enberg <penberg@kernel.org>
Cc: Minchan Kim <minchan@kernel.org>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>,
Leonid Moiseichuk <leonid.moiseichuk@nokia.com>
Subject: Re: vmevent: question?
Date: Mon, 30 Apr 2012 00:54:18 -0700 [thread overview]
Message-ID: <20120430075417.GA8438@lizard> (raw)
In-Reply-To: <CAOJsxLE3A3b5HSrRm0NVCBmzv7AAs-RWEiZC1BL=se309+=WTA@mail.gmail.com>
Hello Pekka,
On Mon, Apr 30, 2012 at 10:35:02AM +0300, Pekka Enberg wrote:
> > vmevent_smaple gathers all registered values to report to user if vmevent match.
> > But the time gap between vmevent match check and vmevent_sample_attr could make error
> > so user could confuse.
> >
> > Q 1. Why do we report _all_ registered vmstat value?
> > A A In my opinion, it's okay just to report _a_ value vmevent_match happens.
>
> It makes the userspace side simpler for "lowmem notification" use
> case. I'm open to changing the ABI if it doesn't make the userspace
> side too complex.
Yep. Actually, I'd like to add something like 'file_pages - shmem'
attribute, and reporting both (i.e. this new attr and free_pages)
values at the same time (even if just one crossed the threshold).
Reporting all the values would help userspace logic (so it won't
need to read /proc again).
> > Q 4. Do you have any plan for this patchset to merge into mainline?
>
> Yes, I'm interested in pushing it forward if we can show that the ABI
> makes sense, is stable and generic enough, and fixes real world
> problems.
It seems to be a pretty nice driver. Speaking of ABI, the only thing
I personally dislike is VMEVENT_CONFIG_MAX_ATTRS (i.e. fixed-size
array in vmevent_config)... but I guess it's pretty easy to make
it variable-sized array... was there any particular reason to make
the _MAX thing?
Thanks!
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
--
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>
next prev parent reply other threads:[~2012-04-30 7:55 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-30 7:06 vmevent: question? Minchan Kim
2012-04-30 7:06 ` Minchan Kim
2012-04-30 7:35 ` Pekka Enberg
2012-04-30 7:35 ` Pekka Enberg
2012-04-30 7:52 ` Minchan Kim
2012-04-30 7:52 ` Minchan Kim
2012-04-30 8:01 ` Pekka Enberg
2012-04-30 8:01 ` Pekka Enberg
2012-04-30 8:36 ` Minchan Kim
2012-04-30 8:36 ` Minchan Kim
2012-05-03 7:24 ` Pekka Enberg
2012-05-03 7:24 ` Pekka Enberg
2012-05-03 7:57 ` Minchan Kim
2012-05-03 7:57 ` Minchan Kim
2012-05-03 8:07 ` Pekka Enberg
2012-05-03 8:07 ` Pekka Enberg
2012-05-03 8:13 ` Minchan Kim
2012-05-03 8:13 ` Minchan Kim
2012-04-30 7:54 ` Anton Vorontsov [this message]
2012-04-30 7:54 ` Anton Vorontsov
2012-04-30 8:03 ` Pekka Enberg
2012-04-30 8:03 ` Pekka Enberg
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=20120430075417.GA8438@lizard \
--to=cbouatmailru@gmail.com \
--cc=leonid.moiseichuk@nokia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=mingo@elte.hu \
--cc=penberg@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.