On Wed, Feb 14, 2018 at 3:59 AM, Shakeel Butt <shakeelb@xxxxxxxxxx> wrote: > On Tue, Feb 13, 2018 at 2:20 PM, Shakeel Butt <shakeelb@xxxxxxxxxx> wrote: [...] >>>>> Something like FAN_GROUP_QUEUE (better name is welcome) >>>>> which is mutually exclusive (?) with FAN_UNLIMITED_QUEUE. >>>>> >> >> How about FAN_CHARGE_MEMCG? >> I am not crazy about this name. Imagine a user that writes a file system listener that is going to run inside a container. The user doesn't need to know about the container or what is memcg and what is memcg charging. IMO, we need to hide those implementation details from the user and yet encourage user to opt-in for memcg charging... or do we? > > Also should there be a similar flag for inotify_init1() as well? > This question changed my perspective on the fanotify_init() flag. Unlike with fanotify, for inotify, is it the sysadmin that determines the size of the queue of future listeners by setting /proc/sys/fs/inotify/max_queued_events IMO, there is little justification for a program to opt-out of memcg charging if the sysadmin opts-in for memcg charging. Anyone disagrees with that claim? So how about /proc/sys/fs/inotify/charge_memcg which defaults to CONFIG_INOTIFY_CHARGE_MEMCG which defaults to N. Then sysadmin can opt-in/out of new behavior and distro can opt-in for new behavior by default and programs don't need to be recompiled. I think that should be enough to address the concern of changing existing behavior. The same logic could also apply to fanotify, excpet we may want to use sysfs instead of procfs. The question is: do we need a separate knob for charging memcg for inotify and fanotify or same knob can control both? I can't think of a reason why we really need 2 knobs, but maybe its just nicer to have the inotify knob next to the existing max_queued_events knob. Thanks, Amir.
