Hello, Michael! > > Hm, basically any cgroup which had some pagecache, associated during the > > lifetime, will spend some time in the dying state. This means that for > > most cgroups this number will be non-zero for some amount of time, > > which depends on global memory pressure. > > It's also very implementation-defined, and will be likely changed > > in the following kernel versions. > > > > So, I'm not sure, that such an example will be useful for a user. > > Until this number is huge and constantly growing, it shouldn't be > > interesting for an user at all. > > Fair enough. I added some vague text about resources needing to be freed > before the cgroup is destroyed. See below. > > > >> nr_dying_descendants > >> This is the total number of dying descendant cgroups > >> underneath this cgroup. A cgroup enters the dying state > >> after being deleted. It remains in that state for an > >> undefined period (which will depend on system load) > >> before being destroyed. > >> > >> A process can't be made a member of a dying cgroup, and > >> a dying cgroup can't be brought back to life. > > > > So, maybe it worth it to add a statement, that some amount of dying cgroups > > is normal and it's not a signal of any problem? > > Okay, I added some text along those lines. The first paragraph now reads: > > nr_dying_descendants > This is the total number of dying descendant cgroups > underneath this cgroup. A cgroup enters the dying state > after being deleted. It remains in that state for an > undefined period (which will depend on system load) > while resources are freed before the cgroup is > destroyed. Note that the presence of some cgroups in > the dying state is normal, and is not indicative of any > problem. Looks good to me! Reviewed-by: Roman Gushchin <guro@xxxxxx> Thank you! -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
