vmpressure: implement strict mode

Currently, applications are notified for the level they registered for _plus_ higher levels.

This is a problem if the 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 critical. To do this, the application has to register a different fd for each event. However, fd low is always going to be notified and and all fds are going to be notified on level critical.

Strict mode solves this problem by strictly notifiying the event an fd has registered for. It's optional. By default we still notify on higher levels.

Signed-off-by Luiz Capitulino <[email protected]>

---

PS: I'm following the discussion on the event storm problem, but I believe
strict mode is orthogonal to what has been suggested (although the patches conflict)

 Documentation/cgroups/memory.txt | 10 ++++++----
 mm/vmpressure.c                  | 19 +++++++++++++++++--
 2 files changed, 23 insertions(+), 6 deletions(-)

Documentation/cgroups/memory.txt +6 -4

index ddf4f93..3c589cf 100644
@@ -807,12 +807,14 @@ register a notification, an application must:
 
 - create an eventfd using eventfd(2);
 - open memory.pressure_level;
-- write string like "<event_fd> <fd of memory.pressure_level> <level>"
+- write string like "<event_fd> <fd of memory.pressure_level> <level> [strict]"
   to cgroup.event_control.
 
-Application will be notified through eventfd when memory pressure is at
-the specific level (or higher). Read/write operations to
-memory.pressure_level are no implemented.
+Applications will be notified through eventfd when memory pressure is at
+the specific level or higher. If strict is passed, then applications
+will only be notified when memory pressure reaches the specified level.
+
+Read/write operations to memory.pressure_level are no implemented.
 
 Test:
 

mm/vmpressure.c +17 -3

index 736a601..6289ede 100644
@@ -137,6 +137,7 @@ static enum vmpressure_levels vmpressure_calc_level(unsigned long scanned,
 struct vmpressure_event {
        struct eventfd_ctx *efd;
        enum vmpressure_levels level;
+       bool strict_mode;
        struct list_head node;
 };
 

@@ -153,6 +154,9 @@ static bool vmpressure_event(struct vmpressure *vmpr,
 
        list_for_each_entry(ev, &vmpr->events, node) {
                if (level >= ev->level) {
+                       /* strict mode ensures level == ev->level */
+                       if (ev->strict_mode && level != ev->level)
+                               continue;
                        eventfd_signal(ev->efd, 1);
                        signalled = true;
                }

@@ -292,7 +296,7 @@ void vmpressure_prio(gfp_t gfp, struct mem_cgroup *memcg, int prio)
  * infrastructure, so that the notifications will be delivered to the
  * @eventfd. The @args parameter is a string that denotes pressure level
  * threshold (one of vmpressure_str_levels, i.e. "low", "medium", or
- * "critical").
+ * "critical") and optionally a different operating mode (i.e. "strict")
  *
  * This function should not be used directly, just pass it to (struct
  * cftype).register_event, and then cgroup core will handle everything by

@@ -303,22 +307,33 @@ int vmpressure_register_event(struct cgroup *cg, struct cftype *cft,
 {
        struct vmpressure *vmpr = cg_to_vmpressure(cg);
        struct vmpressure_event *ev;
+       bool smode = false;
+       const char *p;
        int level;
 
        for (level = 0; level < VMPRESSURE_NUM_LEVELS; level++) {
-               if (!strcmp(vmpressure_str_levels[level], args))
+               p = vmpressure_str_levels[level];
+               if (!strncmp(p, args, strlen(p)))
                        break;
        }
 
        if (level >= VMPRESSURE_NUM_LEVELS)
                return -EINVAL;
 
+       p = strchr(args, ' ');
+       if (p) {
+               if (strncmp(++p, "strict", 6))
+                       return -EINVAL;
+               smode = true;
+       }
+
        ev = kzalloc(sizeof(*ev), GFP_KERNEL);
        if (!ev)
                return -ENOMEM;
 
        ev->efd = eventfd;
        ev->level = level;
+       ev->strict_mode = smode;
 
        mutex_lock(&vmpr->events_lock);
        list_add(&ev->node, &vmpr->events);
--

1.8.1.4

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

+ Ms. Kim,

she already raised this issue at another mail thread.

Thank you,
Kyungmin Park

Quoted 117 lines · Luiz Capitulino

Currently, applications are notified for the level they registered for _plus_ higher levels.

This is a problem if the 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 critical. To do this, the application has to register a different fd for each event. However, fd low is always going to be notified and and all fds are going to be notified on level critical.

Strict mode solves this problem by strictly notifiying the event an fd has registered for. It's optional. By default we still notify on higher levels.

Signed-off-by Luiz Capitulino <[email protected]>

---

PS: I'm following the discussion on the event storm problem, but I believe
strict mode is orthogonal to what has been suggested (although the patches conflict)

 Documentation/cgroups/memory.txt | 10 ++++++----
 mm/vmpressure.c                  | 19 +++++++++++++++++--
 2 files changed, 23 insertions(+), 6 deletions(-)

Documentation/cgroups/memory.txt +6 -4

index ddf4f93..3c589cf 100644
@@ -807,12 +807,14 @@ register a notification, an application must:
 
 - create an eventfd using eventfd(2);
 - open memory.pressure_level;
-- write string like "<event_fd> <fd of memory.pressure_level> <level>"
+- write string like "<event_fd> <fd of memory.pressure_level> <level> [strict]"
   to cgroup.event_control.
 
-Application will be notified through eventfd when memory pressure is at
-the specific level (or higher). Read/write operations to
-memory.pressure_level are no implemented.
+Applications will be notified through eventfd when memory pressure is at
+the specific level or higher. If strict is passed, then applications
+will only be notified when memory pressure reaches the specified level.
+
+Read/write operations to memory.pressure_level are no implemented.
 
 Test:
 

mm/vmpressure.c +17 -3

index 736a601..6289ede 100644
@@ -137,6 +137,7 @@ static enum vmpressure_levels vmpressure_calc_level(unsigned long scanned,
 struct vmpressure_event {
        struct eventfd_ctx *efd;
        enum vmpressure_levels level;
+       bool strict_mode;
        struct list_head node;
 };
 

@@ -153,6 +154,9 @@ static bool vmpressure_event(struct vmpressure *vmpr,
 
        list_for_each_entry(ev, &vmpr->events, node) {
                if (level >= ev->level) {
+                       /* strict mode ensures level == ev->level */
+                       if (ev->strict_mode && level != ev->level)
+                               continue;
                        eventfd_signal(ev->efd, 1);
                        signalled = true;
                }

@@ -292,7 +296,7 @@ void vmpressure_prio(gfp_t gfp, struct mem_cgroup *memcg, int prio)
  * infrastructure, so that the notifications will be delivered to the
  * @eventfd. The @args parameter is a string that denotes pressure level
  * threshold (one of vmpressure_str_levels, i.e. "low", "medium", or
- * "critical").
+ * "critical") and optionally a different operating mode (i.e. "strict")
  *
  * This function should not be used directly, just pass it to (struct
  * cftype).register_event, and then cgroup core will handle everything by

@@ -303,22 +307,33 @@ int vmpressure_register_event(struct cgroup *cg, struct cftype *cft,
 {
        struct vmpressure *vmpr = cg_to_vmpressure(cg);
        struct vmpressure_event *ev;
+       bool smode = false;
+       const char *p;
        int level;
 
        for (level = 0; level < VMPRESSURE_NUM_LEVELS; level++) {
-               if (!strcmp(vmpressure_str_levels[level], args))
+               p = vmpressure_str_levels[level];
+               if (!strncmp(p, args, strlen(p)))
                        break;
        }
 
        if (level >= VMPRESSURE_NUM_LEVELS)
                return -EINVAL;
 
+       p = strchr(args, ' ');
+       if (p) {
+               if (strncmp(++p, "strict", 6))
+                       return -EINVAL;
+               smode = true;
+       }
+
        ev = kzalloc(sizeof(*ev), GFP_KERNEL);
        if (!ev)
                return -ENOMEM;
 
        ev->efd = eventfd;
        ev->level = level;
+       ev->strict_mode = smode;
 
        mutex_lock(&vmpr->events_lock);
        list_add(&ev->node, &vmpr->events);
--

1.8.1.4

Quoted 5 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Please see "[PATCH v3] memcg: event control at vmpressure". mail thread. (and also the thread I sent last Saturday.)
There was discussion on this mode not sending lower events when "level != ev->level".

Currently, applications are notified for the level they registered for _plus_ higher levels.

This is a problem if the 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 critical. To do this, the application has to register a different fd for each event. However, fd low is always going to be notified and and all fds are going to be notified on level critical.

Strict mode solves this problem by strictly notifiying the event an fd has registered for. It's optional. By default we still notify on higher levels.

Signed-off-by Luiz Capitulino <[email protected]>

Quoted 10 lines · Luiz Capitulino

Currently, applications are notified for the level they registered for _plus_ higher levels.

This is a problem if the 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 critical. To do this, the application has to register a different fd for each event. However, fd low is always going to be notified and and all fds are going to be notified on level critical.

Quoted 5 lines

Strict mode solves this problem by strictly notifiying the event an fd has registered for. It's optional. By default we still notify on higher levels.

Signed-off-by Luiz Capitulino <[email protected]>

In the documentation I would add more information about why exactly the strict mode makes sense.

For example, the non-strict fd listener hooked onto the low level makes sense for apps that just monitor reclaiming activity (like current Android Activity Manager), hooking onto 'medium' non-strict mode makes sense for simple load-balancing logic, and the new strict mode is for the cases when an application wants to implement some fancy logic as it makes a decision based on a concrete level.

Otherwise, it looks good.

Acked-by Anton Vorontsov <[email protected]>

Currently, applications are notified for the level they registered for _plus_ higher levels.

This is a problem if the 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 critical. To do this, the application has to register a different fd for each event. However, fd low is always going to be notified and and all fds are going to be notified on level critical.

Strict mode solves this problem by strictly notifiying the event an fd has registered for. It's optional. By default we still notify on higher levels.

Signed-off-by Luiz Capitulino <[email protected]>

Quoted 10 lines · Luiz Capitulino

Currently, applications are notified for the level they registered for _plus_ higher levels.

This is a problem if the 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 critical. To do this, the application has to register a different fd for each event. However, fd low is always going to be notified and and all fds are going to be notified on level critical.

Quoted 5 lines

Strict mode solves this problem by strictly notifiying the event an fd has registered for. It's optional. By default we still notify on higher levels.

Signed-off-by Luiz Capitulino <[email protected]>

Acked-by Minchan Kim <[email protected]>

Shouldn't we make this default?

Quoted 15 lines · Minchan Kim

Quoted 14 lines · Luiz Capitulino

Currently, applications are notified for the level they registered for _plus_ higher levels.

This is a problem if the 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 critical. To do this, the application has to register a different fd for each event. However, fd low is always going to be notified and and all fds are going to be notified on level critical.

Strict mode solves this problem by strictly notifiying the event an fd has registered for. It's optional. By default we still notify on higher levels.

Quoted 4 lines

Quoted 1 line

Signed-off-by Luiz Capitulino <[email protected]>

Acked-by Minchan Kim <[email protected]>

Shouldn't we make this default?

The interface is not there for long but still, changing it is always quite tricky. And the users who care can be modified really easily so I would stick with the original default.

Signature · 9 lines

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Hello Michal,

Quoted 21 lines · Michal Hocko

Quoted 19 lines · Minchan Kim

Quoted 10 lines · Luiz Capitulino

Currently, applications are notified for the level they registered for _plus_ higher levels.

This is a problem if the 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 critical. To do this, the application has to register a different fd for each event. However, fd low is always going to be notified and and all fds are going to be notified on level critical.

Quoted 5 lines

Strict mode solves this problem by strictly notifiying the event an fd has registered for. It's optional. By default we still notify on higher levels.

Signed-off-by Luiz Capitulino <[email protected]>

Acked-by Minchan Kim <[email protected]>

Shouldn't we make this default?

Quoted 3 lines

The interface is not there for long but still, changing it is always quite tricky. And the users who care can be modified really easily so I would stick with the original default.

Yeb, I am not strong against to stick old at a moment but at least, this patch makes more sense to me so I'd like to know why we didn't do it from the beginning. Surely, Anton has a answer.

Quoted 14 lines · Luiz Capitulino

Currently, applications are notified for the level they registered for _plus_ higher levels.

This is a problem if the 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 critical. To do this, the application has to register a different fd for each event. However, fd low is always going to be notified and and all fds are going to be notified on level critical.

Strict mode solves this problem by strictly notifiying the event an fd has registered for. It's optional. By default we still notify on higher levels.

Quoted 1 line

Signed-off-by Luiz Capitulino <[email protected]>

Acked-by Minchan Kim <[email protected]>

Shouldn't we make this default?
What do you think about it?

Currently, applications are notified for the level they registered for _plus_ higher levels.

This is a problem if the 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 critical. To do this, the application has to register a different fd for each event. However, fd low is always going to be notified and and all fds are going to be notified on level critical.

Strict mode solves this problem by strictly notifiying the event an fd has registered for. It's optional. By default we still notify on higher levels.

Signed-off-by Luiz Capitulino <[email protected]>

---

PS: I'm following the discussion on the event storm problem, but I believe
strict mode is orthogonal to what has been suggested (although the patches conflict)

 Documentation/cgroups/memory.txt | 10 ++++++----
 mm/vmpressure.c                  | 19 +++++++++++++++++--
 2 files changed, 23 insertions(+), 6 deletions(-)

Documentation/cgroups/memory.txt +0 -0

index ddf4f93..3c589cf 100644
@@ -807,12 +807,14 @@ register a notification, an application must:
 
 - create an eventfd using eventfd(2);
 - open memory.pressure_level;

Documentation/cgroups/memory.txt +2 -0

+
+Read/write operations to memory.pressure_level are no implemented.
 
 Test:
 

mm/vmpressure.c +0 -0

index 736a601..6289ede 100644

mm/vmpressure.c +16 -2

 	struct list_head node;
 };
 

@@ -153,6 +154,9 @@ static bool vmpressure_event(struct vmpressure *vmpr,
 
 	list_for_each_entry(ev, &vmpr->events, node) {
 		if (level >= ev->level) {
+			/* strict mode ensures level == ev->level */
+			if (ev->strict_mode && level != ev->level)
+				continue;
 			eventfd_signal(ev->efd, 1);
 			signalled = true;
 		}

@@ -292,7 +296,7 @@ void vmpressure_prio(gfp_t gfp, struct mem_cgroup *memcg, int prio)
  * infrastructure, so that the notifications will be delivered to the
  * @eventfd. The @args parameter is a string that denotes pressure level
  * threshold (one of vmpressure_str_levels, i.e. "low", "medium", or
- * "critical").
+ * "critical") and optionally a different operating mode (i.e. "strict")
  *
  * This function should not be used directly, just pass it to (struct
  * cftype).register_event, and then cgroup core will handle everything by

@@ -303,22 +307,33 @@ int vmpressure_register_event(struct cgroup *cg, struct cftype *cft,
 {
 	struct vmpressure *vmpr = cg_to_vmpressure(cg);
 	struct vmpressure_event *ev;
+	bool smode = false;
+	const char *p;
 	int level;
 
 	for (level = 0; level < VMPRESSURE_NUM_LEVELS; level++) {
-		if (!strcmp(vmpressure_str_levels[level], args))
+		p = vmpressure_str_levels[level];
+		if (!strncmp(p, args, strlen(p)))
 			break;
 	}
 
 	if (level >= VMPRESSURE_NUM_LEVELS)
 		return -EINVAL;
 
+	p = strchr(args, ' ');
+	if (p) {
+		if (strncmp(++p, "strict", 6))
+			return -EINVAL;
+		smode = true;
+	}
+
 	ev = kzalloc(sizeof(*ev), GFP_KERNEL);
 	if (!ev)
 		return -ENOMEM;
 
 	ev->efd = eventfd;
 	ev->level = level;
+	ev->strict_mode = smode;
 
 	mutex_lock(&vmpr->events_lock);
 	list_add(&ev->node, &vmpr->events);

Signature · 7 lines

1.8.1.4

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Quoted 9 lines · Luiz Capitulino

Currently, applications are notified for the level they registered for _plus_ higher levels.

This is a problem if the 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 critical. To do this, the application has to register a different fd for each event. However, fd low is always going to be notified and and all fds are going to be notified on level critical.

OK, I am not user of this interface but I thought that the application would take an action of the highest level it gets notification. But yes this might get clumsy to implement.

Quoted 3 lines

Strict mode solves this problem by strictly notifiying the event an fd has registered for. It's optional. By default we still notify on higher levels.

OK, makes some sense to me and it should work with the proposed edge trigerring as well.

Quoted 23 lines

Signed-off-by Luiz Capitulino <[email protected]>

---

PS: I'm following the discussion on the event storm problem, but I believe
strict mode is orthogonal to what has been suggested (although the patches conflict)

 Documentation/cgroups/memory.txt | 10 ++++++----
 mm/vmpressure.c                  | 19 +++++++++++++++++--
 2 files changed, 23 insertions(+), 6 deletions(-)

Documentation/cgroups/memory.txt +1 -1

index ddf4f93..3c589cf 100644
@@ -807,12 +807,14 @@ register a notification, an application must:
 
 - create an eventfd using eventfd(2);
 - open memory.pressure_level;
-- write string like "<event_fd> <fd of memory.pressure_level> <level>"
+- write string like "<event_fd> <fd of memory.pressure_level> <level> [strict]"
   to cgroup.event_control.
 

Documentation/cgroups/memory.txt register a notification, an application must: · line 815

Quoted 6 lines

Documentation/cgroups/memory.txt +3 -3

-Application will be notified through eventfd when memory pressure is at
-the specific level (or higher). Read/write operations to
-memory.pressure_level are no implemented.
+Applications will be notified through eventfd when memory pressure is at
+the specific level or higher. If strict is passed, then applications
+will only be notified when memory pressure reaches the specified level.

It would be good to describe when is strick and when the default appropriate.

Quoted 5 lines

Documentation/cgroups/memory.txt +2 -0

+
+Read/write operations to memory.pressure_level are no implemented.
 
 Test:
 

mm/vmpressure.c static enum vmpressure_levels vmpressure_calc_level(unsigned long scanned, · line 140

Quoted 9 lines

mm/vmpressure.c +1 -0

index 736a601..6289ede 100644
@@ -137,6 +137,7 @@ static enum vmpressure_levels vmpressure_calc_level(unsigned long scanned,
 struct vmpressure_event {
 	struct eventfd_ctx *efd;
 	enum vmpressure_levels level;
+	bool strict_mode;

Any reason to not using a flag for this? If there are any other modes to come them we would end up with zilions of bools which is not very nice.

Quoted 61 lines

mm/vmpressure.c +16 -2

 	struct list_head node;
 };
 

@@ -153,6 +154,9 @@ static bool vmpressure_event(struct vmpressure *vmpr,
 
 	list_for_each_entry(ev, &vmpr->events, node) {
 		if (level >= ev->level) {
+			/* strict mode ensures level == ev->level */
+			if (ev->strict_mode && level != ev->level)
+				continue;
 			eventfd_signal(ev->efd, 1);
 			signalled = true;
 		}

@@ -292,7 +296,7 @@ void vmpressure_prio(gfp_t gfp, struct mem_cgroup *memcg, int prio)
  * infrastructure, so that the notifications will be delivered to the
  * @eventfd. The @args parameter is a string that denotes pressure level
  * threshold (one of vmpressure_str_levels, i.e. "low", "medium", or
- * "critical").
+ * "critical") and optionally a different operating mode (i.e. "strict")
  *
  * This function should not be used directly, just pass it to (struct
  * cftype).register_event, and then cgroup core will handle everything by

@@ -303,22 +307,33 @@ int vmpressure_register_event(struct cgroup *cg, struct cftype *cft,
 {
 	struct vmpressure *vmpr = cg_to_vmpressure(cg);
 	struct vmpressure_event *ev;
+	bool smode = false;
+	const char *p;
 	int level;
 
 	for (level = 0; level < VMPRESSURE_NUM_LEVELS; level++) {
-		if (!strcmp(vmpressure_str_levels[level], args))
+		p = vmpressure_str_levels[level];
+		if (!strncmp(p, args, strlen(p)))
 			break;
 	}
 
 	if (level >= VMPRESSURE_NUM_LEVELS)
 		return -EINVAL;
 
+	p = strchr(args, ' ');
+	if (p) {
+		if (strncmp(++p, "strict", 6))
+			return -EINVAL;
+		smode = true;
+	}
+
 	ev = kzalloc(sizeof(*ev), GFP_KERNEL);
 	if (!ev)
 		return -ENOMEM;
 
 	ev->efd = eventfd;
 	ev->level = level;
+	ev->strict_mode = smode;
 
 	mutex_lock(&vmpr->events_lock);
 	list_add(&ev->node, &vmpr->events);

Signature · 1 line

1.8.1.4

Quoted 5 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Documentation/cgroups/memory.txt +4 -1

@@ -303,22 +307,33 @@ int vmpressure_register_event(struct cgroup *cg, struct cftype *cft,
 {
 	struct vmpressure *vmpr = cg_to_vmpressure(cg);
 	struct vmpressure_event *ev;
+	bool smode = false;
+	const char *p;
 	int level;
 
 	for (level = 0; level < VMPRESSURE_NUM_LEVELS; level++) {
-		if (!strcmp(vmpressure_str_levels[level], args))
+		p = vmpressure_str_levels[level];
+		if (!strncmp(p, args, strlen(p)))
 			break;
 	}
 

Hi!

Quoted 6 lines

Documentation/cgroups/memory.txt +0 -0

index ddf4f93..3c589cf 100644
@@ -807,12 +807,14 @@ register a notification, an application must:
 

Documentation/cgroups/memory.txt register a notification, an application must: · line 812

Quoted 6 lines

Documentation/cgroups/memory.txt +1 -1

 - create an eventfd using eventfd(2);
 - open memory.pressure_level;
-- write string like "<event_fd> <fd of memory.pressure_level> <level>"
+- write string like "<event_fd> <fd of memory.pressure_level> <level> [strict]"
   to cgroup.event_control.
 

This is.. pretty strange interface. Would it be cleaner to do ioctl()? New syscall?

Quoted 8 lines · On Mon, 1 Jul 2013 10:51:03 +0200 Pavel Machek <[email protected]> wrote:

Hi!

Quoted 6 lines

Documentation/cgroups/memory.txt +0 -0

index ddf4f93..3c589cf 100644
@@ -807,12 +807,14 @@ register a notification, an application must:
 

Quoted 9 lines

Documentation/cgroups/memory.txt register a notification, an application must: · line 812

Quoted 6 lines

Documentation/cgroups/memory.txt +1 -1

 - create an eventfd using eventfd(2);
 - open memory.pressure_level;
-- write string like "<event_fd> <fd of memory.pressure_level> <level>"
+- write string like "<event_fd> <fd of memory.pressure_level> <level> [strict]"
   to cgroup.event_control.
 

This is.. pretty strange interface. Would it be cleaner to do ioctl()? New syscall?

Are you referring to my new mode or to the whole thing?

Quoted 21 lines · Luiz Capitulino

Quoted 17 lines · On Mon, 1 Jul 2013 10:51:03 +0200 Pavel Machek <[email protected]> wrote:

Hi!

Documentation/cgroups/memory.txt register a notification, an application must: · line 812

Quoted 12 lines

Documentation/cgroups/memory.txt +1 -1

index ddf4f93..3c589cf 100644
@@ -807,12 +807,14 @@ register a notification, an application must:
 
 - create an eventfd using eventfd(2);
 - open memory.pressure_level;
-- write string like "<event_fd> <fd of memory.pressure_level> <level>"
+- write string like "<event_fd> <fd of memory.pressure_level> <level> [strict]"
   to cgroup.event_control.
 

This is.. pretty strange interface. Would it be cleaner to do ioctl()? New syscall?

Quoted 1 line

Are you referring to my new mode or to the whole thing?

Well. The interface was already very strange and you made it even worse.