On Tue, 2 Jul 2013 10:24:09 -0700
Anton Vorontsov wrote:
> > Honestly, what Andrew suggested is the best design for me: apps
> > are notified on all events but the event name is sent to the application.
>
> I am fine with this approach (or any other, I'm really indifferent to the
> API itself
On Tue, Jul 02, 2013 at 10:59:11AM -0400, Luiz Capitulino wrote:
> 2. Considering the interface can be extended, how can new applications
> work on backwards mode? Say, we add ultra-critical on 3.12 and
> I update my application to work on it, how will my application
> work on 3.11?
On Fri, 28 Jun 2013 17:56:37 -0700
Anton Vorontsov wrote:
> On Fri, Jun 28, 2013 at 03:44:02PM -0400, Luiz Capitulino wrote:
> > > Why can't you use poll() and demultiplex the events? Check if there is an
> > > event in the crit fd, and if there is, then just ignore all the rest.
> >
> > This
On Fri 28-06-13 17:56:37, Anton Vorontsov wrote:
> On Fri, Jun 28, 2013 at 03:44:02PM -0400, Luiz Capitulino wrote:
> > > Why can't you use poll() and demultiplex the events? Check if there is an
> > > event in the crit fd, and if there is, then just ignore all the rest.
> >
> > This may be a
2013/7/2 Anton Vorontsov :
> On Mon, Jul 01, 2013 at 05:22:36PM +0900, Hyunhee Kim wrote:
>> >> > > for each event in memory.pressure_level; do
>> >> > > /* register eventfd to be notified on "event" */
>> >> > > done
>> >> >
>> >> > This scheme registers "all" events.
>> >>
>> >> Yes, because I
On Tue, Jul 02, 2013 at 10:59:11AM -0400, Luiz Capitulino wrote:
2. Considering the interface can be extended, how can new applications
work on backwards mode? Say, we add ultra-critical on 3.12 and
I update my application to work on it, how will my application
work on 3.11?
It
On Tue, 2 Jul 2013 10:24:09 -0700
Anton Vorontsov an...@enomsg.org wrote:
Honestly, what Andrew suggested is the best design for me: apps
are notified on all events but the event name is sent to the application.
I am fine with this approach (or any other, I'm really indifferent to the
API
2013/7/2 Anton Vorontsov an...@enomsg.org:
On Mon, Jul 01, 2013 at 05:22:36PM +0900, Hyunhee Kim wrote:
for each event in memory.pressure_level; do
/* register eventfd to be notified on event */
done
This scheme registers all events.
Yes, because I thought that's the
On Fri 28-06-13 17:56:37, Anton Vorontsov wrote:
On Fri, Jun 28, 2013 at 03:44:02PM -0400, Luiz Capitulino wrote:
Why can't you use poll() and demultiplex the events? Check if there is an
event in the crit fd, and if there is, then just ignore all the rest.
This may be a valid
On Fri, 28 Jun 2013 17:56:37 -0700
Anton Vorontsov an...@enomsg.org wrote:
On Fri, Jun 28, 2013 at 03:44:02PM -0400, Luiz Capitulino wrote:
Why can't you use poll() and demultiplex the events? Check if there is an
event in the crit fd, and if there is, then just ignore all the rest.
On Mon, Jul 01, 2013 at 05:22:36PM +0900, Hyunhee Kim wrote:
> >> > > for each event in memory.pressure_level; do
> >> > > /* register eventfd to be notified on "event" */
> >> > > done
> >> >
> >> > This scheme registers "all" events.
> >>
> >> Yes, because I thought that's the user-case that
2013/6/29 Anton Vorontsov :
> On Fri, Jun 28, 2013 at 03:44:02PM -0400, Luiz Capitulino wrote:
>> > Why can't you use poll() and demultiplex the events? Check if there is an
>> > event in the crit fd, and if there is, then just ignore all the rest.
>>
>> This may be a valid workaround for current
2013/6/29 Anton Vorontsov an...@enomsg.org:
On Fri, Jun 28, 2013 at 03:44:02PM -0400, Luiz Capitulino wrote:
Why can't you use poll() and demultiplex the events? Check if there is an
event in the crit fd, and if there is, then just ignore all the rest.
This may be a valid workaround for
On Mon, Jul 01, 2013 at 05:22:36PM +0900, Hyunhee Kim wrote:
for each event in memory.pressure_level; do
/* register eventfd to be notified on event */
done
This scheme registers all events.
Yes, because I thought that's the user-case that matters for activity
manager :)
On Fri, Jun 28, 2013 at 03:44:02PM -0400, Luiz Capitulino wrote:
> > Why can't you use poll() and demultiplex the events? Check if there is an
> > event in the crit fd, and if there is, then just ignore all the rest.
>
> This may be a valid workaround for current kernels, but application
>
On Fri, 28 Jun 2013 11:55:47 -0700
Anton Vorontsov wrote:
> On Fri, Jun 28, 2013 at 02:45:07PM -0400, Luiz Capitulino wrote:
> > On Fri, 28 Jun 2013 10:09:17 -0700
> > Anton Vorontsov wrote:
> >
> > > So, I would now argue that the current scheme is perfectly OK and can do
> > > everything you
On Fri, Jun 28, 2013 at 02:45:07PM -0400, Luiz Capitulino wrote:
> On Fri, 28 Jun 2013 10:09:17 -0700
> Anton Vorontsov wrote:
>
> > So, I would now argue that the current scheme is perfectly OK and can do
> > everything you can do with the "strict" one,
>
> I forgot commenting this bit. This
On Fri, 28 Jun 2013 11:45:47 -0700
Anton Vorontsov wrote:
> On Fri, Jun 28, 2013 at 02:25:58PM -0400, Luiz Capitulino wrote:
> > > > > That's how it's expected to work, because on strict mode you're
> > > > > notified
> > > > > for the level you registered for. So apps registering for critical,
On Fri, Jun 28, 2013 at 02:25:58PM -0400, Luiz Capitulino wrote:
> > > > That's how it's expected to work, because on strict mode you're notified
> > > > for the level you registered for. So apps registering for critical, will
> > > > still be notified on critical just like before.
> > >
> > >
On Fri, 28 Jun 2013 10:09:17 -0700
Anton Vorontsov wrote:
> So, I would now argue that the current scheme is perfectly OK and can do
> everything you can do with the "strict" one,
I forgot commenting this bit. This is not true, because I don't want a
low fd to be notified on critical level. The
On Fri, 28 Jun 2013 10:09:17 -0700
Anton Vorontsov wrote:
> On Fri, Jun 28, 2013 at 09:57:22AM -0700, Anton Vorontsov wrote:
> > On Fri, Jun 28, 2013 at 10:00:27AM -0400, Luiz Capitulino wrote:
> > > On Thu, 27 Jun 2013 22:07:12 -0700
> > > Anton Vorontsov wrote:
> > >
> > > > On Thu, Jun 27,
On Fri, Jun 28, 2013 at 09:57:22AM -0700, Anton Vorontsov wrote:
> On Fri, Jun 28, 2013 at 10:00:27AM -0400, Luiz Capitulino wrote:
> > On Thu, 27 Jun 2013 22:07:12 -0700
> > Anton Vorontsov wrote:
> >
> > > On Thu, Jun 27, 2013 at 09:34:11PM -0700, Anton Vorontsov wrote:
> > > > ... we can add
On Fri, Jun 28, 2013 at 10:00:27AM -0400, Luiz Capitulino wrote:
> On Thu, 27 Jun 2013 22:07:12 -0700
> Anton Vorontsov wrote:
>
> > On Thu, Jun 27, 2013 at 09:34:11PM -0700, Anton Vorontsov wrote:
> > > ... we can add the strict mode and deprecate the
> > > "filtering" -- basically we'll
On Thu, 27 Jun 2013 22:07:12 -0700
Anton Vorontsov wrote:
> On Thu, Jun 27, 2013 at 09:34:11PM -0700, Anton Vorontsov wrote:
> > ... we can add the strict mode and deprecate the
> > "filtering" -- basically we'll implement the idea of requiring that
> > userspace registers a separate fd for each
On Thu, 27 Jun 2013 21:34:11 -0700
Anton Vorontsov wrote:
> On Thu, Jun 27, 2013 at 06:13:53PM -0700, Andrew Morton wrote:
> > On Thu, 27 Jun 2013 17:58:53 -0700 Anton Vorontsov wrote:
> > > Current frequency is 1/(2MB). Suppose we ended up scanning the whole
> > > memory on a 2GB host, this
On Thu, Jun 27, 2013 at 06:13:53PM -0700, Andrew Morton wrote:
> On Thu, 27 Jun 2013 17:58:53 -0700 Anton Vorontsov wrote:
>
> > On Thu, Jun 27, 2013 at 05:34:33PM -0700, Andrew Morton wrote:
> > > > If so, userland daemon would receive lots of events which are no
> > > > interest.
> > >
> > >
On Thu, Jun 27, 2013 at 06:13:53PM -0700, Andrew Morton wrote:
On Thu, 27 Jun 2013 17:58:53 -0700 Anton Vorontsov an...@enomsg.org wrote:
On Thu, Jun 27, 2013 at 05:34:33PM -0700, Andrew Morton wrote:
If so, userland daemon would receive lots of events which are no
interest.
On Thu, 27 Jun 2013 21:34:11 -0700
Anton Vorontsov an...@enomsg.org wrote:
On Thu, Jun 27, 2013 at 06:13:53PM -0700, Andrew Morton wrote:
On Thu, 27 Jun 2013 17:58:53 -0700 Anton Vorontsov an...@enomsg.org wrote:
Current frequency is 1/(2MB). Suppose we ended up scanning the whole
memory
On Thu, 27 Jun 2013 22:07:12 -0700
Anton Vorontsov an...@enomsg.org wrote:
On Thu, Jun 27, 2013 at 09:34:11PM -0700, Anton Vorontsov wrote:
... we can add the strict mode and deprecate the
filtering -- basically we'll implement the idea of requiring that
userspace registers a separate fd
On Fri, Jun 28, 2013 at 10:00:27AM -0400, Luiz Capitulino wrote:
On Thu, 27 Jun 2013 22:07:12 -0700
Anton Vorontsov an...@enomsg.org wrote:
On Thu, Jun 27, 2013 at 09:34:11PM -0700, Anton Vorontsov wrote:
... we can add the strict mode and deprecate the
filtering -- basically we'll
On Fri, Jun 28, 2013 at 09:57:22AM -0700, Anton Vorontsov wrote:
On Fri, Jun 28, 2013 at 10:00:27AM -0400, Luiz Capitulino wrote:
On Thu, 27 Jun 2013 22:07:12 -0700
Anton Vorontsov an...@enomsg.org wrote:
On Thu, Jun 27, 2013 at 09:34:11PM -0700, Anton Vorontsov wrote:
... we can
On Fri, 28 Jun 2013 10:09:17 -0700
Anton Vorontsov an...@enomsg.org wrote:
On Fri, Jun 28, 2013 at 09:57:22AM -0700, Anton Vorontsov wrote:
On Fri, Jun 28, 2013 at 10:00:27AM -0400, Luiz Capitulino wrote:
On Thu, 27 Jun 2013 22:07:12 -0700
Anton Vorontsov an...@enomsg.org wrote:
On Fri, 28 Jun 2013 10:09:17 -0700
Anton Vorontsov an...@enomsg.org wrote:
So, I would now argue that the current scheme is perfectly OK and can do
everything you can do with the strict one,
I forgot commenting this bit. This is not true, because I don't want a
low fd to be notified on
On Fri, Jun 28, 2013 at 02:25:58PM -0400, Luiz Capitulino wrote:
That's how it's expected to work, because on strict mode you're notified
for the level you registered for. So apps registering for critical, will
still be notified on critical just like before.
Suppose you
On Fri, 28 Jun 2013 11:45:47 -0700
Anton Vorontsov an...@enomsg.org wrote:
On Fri, Jun 28, 2013 at 02:25:58PM -0400, Luiz Capitulino wrote:
That's how it's expected to work, because on strict mode you're
notified
for the level you registered for. So apps registering for critical,
On Fri, Jun 28, 2013 at 02:45:07PM -0400, Luiz Capitulino wrote:
On Fri, 28 Jun 2013 10:09:17 -0700
Anton Vorontsov an...@enomsg.org wrote:
So, I would now argue that the current scheme is perfectly OK and can do
everything you can do with the strict one,
I forgot commenting this bit.
On Fri, 28 Jun 2013 11:55:47 -0700
Anton Vorontsov an...@enomsg.org wrote:
On Fri, Jun 28, 2013 at 02:45:07PM -0400, Luiz Capitulino wrote:
On Fri, 28 Jun 2013 10:09:17 -0700
Anton Vorontsov an...@enomsg.org wrote:
So, I would now argue that the current scheme is perfectly OK and can
On Fri, Jun 28, 2013 at 03:44:02PM -0400, Luiz Capitulino wrote:
Why can't you use poll() and demultiplex the events? Check if there is an
event in the crit fd, and if there is, then just ignore all the rest.
This may be a valid workaround for current kernels, but application
behavior will
On Thu, 27 Jun 2013 21:34:11 -0700 Anton Vorontsov wrote:
> On Thu, Jun 27, 2013 at 06:13:53PM -0700, Andrew Morton wrote:
> > On Thu, 27 Jun 2013 17:58:53 -0700 Anton Vorontsov wrote:
> > > Current frequency is 1/(2MB). Suppose we ended up scanning the whole
> > > memory on a 2GB host, this
On Thu, Jun 27, 2013 at 09:34:11PM -0700, Anton Vorontsov wrote:
> ... we can add the strict mode and deprecate the
> "filtering" -- basically we'll implement the idea of requiring that
> userspace registers a separate fd for each level.
Btw, assuming that more levels can be added, there will be
On Thu, Jun 27, 2013 at 06:13:53PM -0700, Andrew Morton wrote:
> On Thu, 27 Jun 2013 17:58:53 -0700 Anton Vorontsov wrote:
> > Current frequency is 1/(2MB). Suppose we ended up scanning the whole
> > memory on a 2GB host, this will give us 1024 hits. Doesn't feel too much*
> > to me... But for
On Thu, 27 Jun 2013 17:58:53 -0700 Anton Vorontsov wrote:
> On Thu, Jun 27, 2013 at 05:34:33PM -0700, Andrew Morton wrote:
> > > If so, userland daemon would receive lots of events which are no interest.
> >
> > "lots"? If vmpressure is generating events at such a high frequency that
> > this
On Thu, Jun 27, 2013 at 05:34:33PM -0700, Andrew Morton wrote:
> > If so, userland daemon would receive lots of events which are no interest.
>
> "lots"? If vmpressure is generating events at such a high frequency that
> this matters then it's already busted?
Current frequency is 1/(2MB).
On Fri, 28 Jun 2013 09:02:01 +0900 Minchan Kim wrote:
> Hi Andrew,
>
> On Thu, Jun 27, 2013 at 03:02:31PM -0700, Andrew Morton wrote:
> > On Wed, 26 Jun 2013 23:17:12 -0400 Luiz Capitulino
> > wrote:
> >
> > > Currently, an eventfd is notified for the level it's registered for
> > > _plus_
Hi Andrew,
On Thu, Jun 27, 2013 at 03:02:31PM -0700, Andrew Morton wrote:
> On Wed, 26 Jun 2013 23:17:12 -0400 Luiz Capitulino
> wrote:
>
> > Currently, an eventfd is notified for the level it's registered for
> > _plus_ higher levels.
> >
> > This is a problem if an application wants to
On Wed, 26 Jun 2013 23:17:12 -0400 Luiz Capitulino
wrote:
> Currently, an eventfd is notified for the level it's registered for
> _plus_ higher levels.
>
> This is a problem if an application wants to implement different
> actions for different levels. For example, an application might want
>
On Fri 28-06-13 00:53:57, Minchan Kim wrote:
> On Thu, Jun 27, 2013 at 11:26:16AM +0200, Michal Hocko wrote:
[...]
> > I still think that edge triggering makes some sense but that one might
> > be rebased on top of this patch. We should still figure out whether the
> > edge triggering is the right
On Thu, Jun 27, 2013 at 11:26:16AM +0200, Michal Hocko wrote:
> On Wed 26-06-13 23:17:12, Luiz Capitulino wrote:
> > Currently, an eventfd is notified for the level it's registered for
> > _plus_ higher levels.
> >
> > This is a problem if an application wants to implement different
> > actions
On Wed, Jun 26, 2013 at 11:17:12PM -0400, Luiz Capitulino wrote:
> Currently, an eventfd is notified for the level it's registered for
> _plus_ higher levels.
>
> This is a problem if an application wants to implement different
> actions for different levels. For example, an application might
On Thu 27-06-13 09:34:07, Luiz Capitulino wrote:
> On Thu, 27 Jun 2013 11:26:16 +0200
> Michal Hocko wrote:
> > On Wed 26-06-13 23:17:12, Luiz Capitulino wrote:
[...]
> > > +Applications can also choose between two notification modes when
> > > +registering an eventfd for memory pressure events:
On Thu, 27 Jun 2013 11:26:16 +0200
Michal Hocko wrote:
> On Wed 26-06-13 23:17:12, Luiz Capitulino wrote:
> > Currently, an eventfd is notified for the level it's registered for
> > _plus_ higher levels.
> >
> > This is a problem if an application wants to implement different
> > actions for
On Wed 26-06-13 23:17:12, Luiz Capitulino wrote:
> Currently, an eventfd is notified for the level it's registered for
> _plus_ higher levels.
>
> This is a problem if an application wants to implement different
> actions for different levels. For example, an application might want
> to release
On Wed 26-06-13 23:17:12, Luiz Capitulino wrote:
Currently, an eventfd is notified for the level it's registered for
_plus_ higher levels.
This is a problem if an application wants to implement different
actions for different levels. For example, an application might want
to release 10% of
On Thu, 27 Jun 2013 11:26:16 +0200
Michal Hocko mho...@suse.cz wrote:
On Wed 26-06-13 23:17:12, Luiz Capitulino wrote:
Currently, an eventfd is notified for the level it's registered for
_plus_ higher levels.
This is a problem if an application wants to implement different
actions for
On Thu 27-06-13 09:34:07, Luiz Capitulino wrote:
On Thu, 27 Jun 2013 11:26:16 +0200
Michal Hocko mho...@suse.cz wrote:
On Wed 26-06-13 23:17:12, Luiz Capitulino wrote:
[...]
+Applications can also choose between two notification modes when
+registering an eventfd for memory pressure
On Wed, Jun 26, 2013 at 11:17:12PM -0400, Luiz Capitulino wrote:
Currently, an eventfd is notified for the level it's registered for
_plus_ higher levels.
This is a problem if an application wants to implement different
actions for different levels. For example, an application might want
to
On Thu, Jun 27, 2013 at 11:26:16AM +0200, Michal Hocko wrote:
On Wed 26-06-13 23:17:12, Luiz Capitulino wrote:
Currently, an eventfd is notified for the level it's registered for
_plus_ higher levels.
This is a problem if an application wants to implement different
actions for
On Fri 28-06-13 00:53:57, Minchan Kim wrote:
On Thu, Jun 27, 2013 at 11:26:16AM +0200, Michal Hocko wrote:
[...]
I still think that edge triggering makes some sense but that one might
be rebased on top of this patch. We should still figure out whether the
edge triggering is the right
On Wed, 26 Jun 2013 23:17:12 -0400 Luiz Capitulino lcapitul...@redhat.com
wrote:
Currently, an eventfd is notified for the level it's registered for
_plus_ higher levels.
This is a problem if an application wants to implement different
actions for different levels. For example, an
Hi Andrew,
On Thu, Jun 27, 2013 at 03:02:31PM -0700, Andrew Morton wrote:
On Wed, 26 Jun 2013 23:17:12 -0400 Luiz Capitulino lcapitul...@redhat.com
wrote:
Currently, an eventfd is notified for the level it's registered for
_plus_ higher levels.
This is a problem if an application
On Fri, 28 Jun 2013 09:02:01 +0900 Minchan Kim minc...@kernel.org wrote:
Hi Andrew,
On Thu, Jun 27, 2013 at 03:02:31PM -0700, Andrew Morton wrote:
On Wed, 26 Jun 2013 23:17:12 -0400 Luiz Capitulino lcapitul...@redhat.com
wrote:
Currently, an eventfd is notified for the level it's
On Thu, Jun 27, 2013 at 05:34:33PM -0700, Andrew Morton wrote:
If so, userland daemon would receive lots of events which are no interest.
lots? If vmpressure is generating events at such a high frequency that
this matters then it's already busted?
Current frequency is 1/(2MB). Suppose we
On Thu, 27 Jun 2013 17:58:53 -0700 Anton Vorontsov an...@enomsg.org wrote:
On Thu, Jun 27, 2013 at 05:34:33PM -0700, Andrew Morton wrote:
If so, userland daemon would receive lots of events which are no interest.
lots? If vmpressure is generating events at such a high frequency that
On Thu, Jun 27, 2013 at 06:13:53PM -0700, Andrew Morton wrote:
On Thu, 27 Jun 2013 17:58:53 -0700 Anton Vorontsov an...@enomsg.org wrote:
Current frequency is 1/(2MB). Suppose we ended up scanning the whole
memory on a 2GB host, this will give us 1024 hits. Doesn't feel too much*
to me...
On Thu, Jun 27, 2013 at 09:34:11PM -0700, Anton Vorontsov wrote:
... we can add the strict mode and deprecate the
filtering -- basically we'll implement the idea of requiring that
userspace registers a separate fd for each level.
Btw, assuming that more levels can be added, there will be a
On Thu, 27 Jun 2013 21:34:11 -0700 Anton Vorontsov an...@enomsg.org wrote:
On Thu, Jun 27, 2013 at 06:13:53PM -0700, Andrew Morton wrote:
On Thu, 27 Jun 2013 17:58:53 -0700 Anton Vorontsov an...@enomsg.org wrote:
Current frequency is 1/(2MB). Suppose we ended up scanning the whole
memory
Currently, an eventfd is notified for the level it's registered for
_plus_ higher levels.
This is a problem if an application wants to implement different
actions for different levels. For example, an application might want
to release 10% of its cache on level low, 50% on medium and 100% on
Currently, an eventfd is notified for the level it's registered for
_plus_ higher levels.
This is a problem if an application wants to implement different
actions for different levels. For example, an application might want
to release 10% of its cache on level low, 50% on medium and 100% on
68 matches
Mail list logo
