cgroup: Explicitly remove core interface files
Tejun Heo
maintainerPATCH 1/2 cgroup: Explicitly remove core interface files
The "cgroup." core interface files bypass the usual interface removal path and get removed recursively along with the cgroup itself. While this works now, the subtle discrepancy gets in the way of implementing common mechanisms.
This patch updates cgroup core interface file handling so that it's consistent with controller interface files. When added, the css is marked CSS_VISIBLE and they're explicitly removed before the cgroup is destroyed.
This doesn't cause user-visible behavior changes.
--- kernel/cgroup/cgroup.c | 35 ++++++++++++++++++++++------------- 1 file changed, 22 insertions(+), 13 deletions(-)
kernel/cgroup/cgroup.c +22 -13
@@ -1573,8 +1573,17 @@ static void css_clear_dir(struct cgroup_ css->flags &= ~CSS_VISIBLE ; -list_for_each_entry (cfts, &css->ss->cfts, node) +if (!css->ss) { +if (cgroup_on_dfl (cgrp)) + cfts = cgroup_base_files; +else + cfts = cgroup1_base_files; +cgroup_addrm_files (css, cgrp, cfts, false); + }else { +list_for_each_entry (cfts, &css->ss->cfts, node) +cgroup_addrm_files (css, cgrp, cfts, false); + } }/**
@@ -1598,14 +1607,16 @@ static int css_populate_dir(struct cgrouelse cfts = cgroup1_base_files; -return cgroup_addrm_files (&cgrp->self, cgrp, cfts, true); - } - -list_for_each_entry (cfts, &css->ss->cfts, node) { - ret =cgroup_addrm_files (css, cgrp, cfts, true); -if (ret <0 ) { - failed_cfts = cfts; - goto err; + ret =cgroup_addrm_files (&cgrp->self, cgrp, cfts, true); +if (ret <0 ) +return ret; + }else { +list_for_each_entry (cfts, &css->ss->cfts, node) { + ret =cgroup_addrm_files (css, cgrp, cfts, true); +if (ret <0 ) { + failed_cfts = cfts; + goto err; + } } }
@@ -5097,10 +5108,8 @@ static int cgroup_destroy_locked(structfor_each_css (css, ssid, cgrp)kill_css (css); -/* -* Remove @cgrp directory along with the base files. @cgrp has an -* extra ref on its kn. -*/ +/* clear and remove @cgrp dir, @cgrp has an extra ref on its kn */ +css_clear_dir (&cgrp->self);kernfs_remove (cgrp->kn);if (parent &&cgroup_is_threaded (cgrp))
Tejun Heo
maintainerPATCH 2/2 Subject: cgroup: Limit event generation frequency
".events" files generate file modified event to notify userland of possible new events. Some of the events can be quite bursty (e.g. memory high event) and generating notification each time is costly and pointless.
This patch implements a event rate limit mechanism. If a new notification is requested before 10ms has passed since the previous notification, the new notification is delayed till then.
As this only delays from the second notification on in a given close cluster of notifications, userland reactions to notifications shouldn't be delayed at all in most cases while avoiding notification storms.
--- include/linux/cgroup-defs.h | 2 ++ kernel/cgroup/cgroup.c | 25 +++++++++++++++++++++++-- 2 files changed, 25 insertions(+), 2 deletions(-)
include/linux/cgroup-defs.h +2 -0
@@ -105,6 +105,8 @@ enum {struct cgroup_file {/* do not access any fields from outside cgroup core */ struct kernfs_node *kn; +unsigned long notified_at; +struct timer_list notify_timer; };/*
kernel/cgroup/cgroup.c +23 -2
@@ -61,6 +61,8 @@#define CGROUP_FILE_NAME_MAX (MAX_CGROUP_TYPE_NAMELEN + \ MAX_CFTYPE_NAME + 2) +/* let's not notify more than 100 times per second */ +#define CGROUP_FILE_NOTIFY_MIN_INTV DIV_ROUND_UP(HZ, 100)/* * cgroup_mutex is the master lock. Any modification to cgroup or its
@@ -1554,6 +1556,8 @@ static void cgroup_rm_file(struct cgroupspin_lock_irq (&cgroup_file_kn_lock); cfile->kn =NULL ;spin_unlock_irq (&cgroup_file_kn_lock); + +del_timer_sync (&cfile->notify_timer); }kernfs_remove_by_name (cgrp->kn,cgroup_file_name (cgrp, cft, name));
@@ -3532,6 +3536,12 @@ static int cgroup_kn_set_ugid(struct kerreturn kernfs_setattr (kn, &iattr); } +static void cgroup_file_notify_timer (struct timer_list *timer) +{ +cgroup_file_notify (container_of(timer ,struct cgroup_file , +notify_timer )); +} +static int cgroup_add_file (struct cgroup_subsys_state *css,struct cgroup *cgrp,struct cftype *cft) {
@@ -3558,6 +3568,8 @@ static int cgroup_add_file(struct cgroupif (cft->file_offset) {struct cgroup_file *cfile = (void *)css + cft->file_offset; +timer_setup (&cfile->notify_timer, cgroup_file_notify_timer,0 ); +spin_lock_irq (&cgroup_file_kn_lock); cfile->kn = kn;spin_unlock_irq (&cgroup_file_kn_lock);
@@ -3807,8 +3819,17 @@ void cgroup_file_notify(struct cgroup_fiunsigned long flags;spin_lock_irqsave (&cgroup_file_kn_lock, flags); -if (cfile->kn) -kernfs_notify (cfile->kn); +if (cfile->kn) { +unsigned long last = cfile->notified_at; +unsigned long next = last +CGROUP_FILE_NOTIFY_MIN_INTV ; + +if (time_in_range (jiffies, last, next)) { +timer_reduce (&cfile->notify_timer, next); + }else { +kernfs_notify (cfile->kn); + cfile->notified_at = jiffies; + } + }spin_unlock_irqrestore (&cgroup_file_kn_lock, flags); }
Tejun Heo
maintainerRe: [PATCH cgroup/for-4.17 2/2] Subject: cgroup: Limit event generation frequency
Quoted 9 lines · Tejun Heo
".events" files generate file modified event to notify userland of possible new events. Some of the events can be quite bursty (e.g. memory high event) and generating notification each time is costly and pointless.
This patch implements a event rate limit mechanism. If a new notification is requested before 10ms has passed since the previous notification, the new notification is delayed till then.
Quoted 6 lines
As this only delays from the second notification on in a given close cluster of notifications, userland reactions to notifications shouldn't be delayed at all in most cases while avoiding notification storms.
Signed-off-by Tejun Heo <[email protected]>
Applied 1-2 to cgroup/for-4.18.
Thanks.
Signature · 1 line
tejun