Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1594597

Re: counting file descriptors with a cgroup controller

From Krzysztof Opasiak <k.opasiak@samsung.com>
Newsgroups linux.kernel
Subject Re: counting file descriptors with a cgroup controller
Date 2017-03-07 21:10 +0100
Message-ID <titAK-46W-11@gated-at.bofh.it> (permalink)
References (1 earlier) <tbNbb-2x5-11@gated-at.bofh.it> <tbP3j-3HN-7@gated-at.bofh.it> <ti6b7-49O-1@gated-at.bofh.it> <timzf-7wm-19@gated-at.bofh.it> <tithn-3Jt-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw



On 03/07/2017 08:41 PM, Tejun Heo wrote:
> Hello, Krzysztof.
>
> On Tue, Mar 07, 2017 at 12:19:52PM +0100, Krzysztof Opasiak wrote:
>> So maybe let me clarify our use case so we can have some more discussion
>> about this. We are dealing with task of monitoring system services on an IoT
>> system. So this system needs to run as long as possible without reboot just
>> like server. In server world almost whole system state is being monitored by
>> services like nagios. They measure each parameter (like cpu, memory etc)
>> with some interval. Unfortunately we cannot use this it in an embedded
>> system due to power consumption.
>
> So, we don't add controllers for specific use case scenarios.  The
> target actually has to be a fundamental resource which can't be
> isolated in a different way.
>
> The use case you're describing is more about working around
> shortcomings in userspace by implemneting a major kernel feature, when
> the said shortcomings can easily be controlled and mitigated from
> userspace - e.g. if running out of fds can't be handled reliably from
> the target application for some reason and the application may lock up
> from the condition, protect the base resources so that a monitoring
> process can always reliably run and let that take a corrective action
> when such condition is detected.
>

In theory that's what we plan to do but we are looking for an efficient 
method of detecting that this particular application is using more fds 
than it should (declared by developer).

Personally, I don't want to use rlimit for this as it ends up returning 
error code from for example open() when we hit the limit. This may lead 
to some unpredictable crashes in  services (esp. those poor proprietary 
binary blobs). Instead of injecting errors to service we would like to 
just get notification that this service has more opened fds than it 
should and ask it to restart in a polite way.

For memory seems to be quite easy to achieve as we can just get eventfd 
notification when application passes given memory usage using memory 
cgroup controller. Maybe you know some efficient method to do the same 
for fds?

Best regards,
-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: counting file descriptors with a cgroup controller Tejun Heo <tj@kernel.org> - 2017-03-06 20:10 +0100
  Re: counting file descriptors with a cgroup controller Krzysztof Opasiak <k.opasiak@samsung.com> - 2017-03-07 13:40 +0100
    Re: counting file descriptors with a cgroup controller Tejun Heo <tj@kernel.org> - 2017-03-07 20:50 +0100
      Re: counting file descriptors with a cgroup controller Krzysztof Opasiak <k.opasiak@samsung.com> - 2017-03-07 21:10 +0100
        Re: counting file descriptors with a cgroup controller Parav Pandit <pandit.parav@gmail.com> - 2017-03-08 04:10 +0100
          Re: counting file descriptors with a cgroup controller Krzysztof Opasiak <k.opasiak@samsung.com> - 2017-03-08 11:30 +0100
        Re: counting file descriptors with a cgroup controller Krzysztof Opasiak <k.opasiak@samsung.com> - 2017-03-08 13:10 +0100
          Re: counting file descriptors with a cgroup controller Tejun Heo <tj@kernel.org> - 2017-03-08 20:10 +0100
        Re: counting file descriptors with a cgroup controller Tejun Heo <tj@kernel.org> - 2017-03-08 15:50 +0100

csiph-web