From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756086AbdCGUHi (ORCPT ); Tue, 7 Mar 2017 15:07:38 -0500 Received: from mailout1.samsung.com ([203.254.224.24]:44937 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751507AbdCGUHX (ORCPT ); Tue, 7 Mar 2017 15:07:23 -0500 X-AuditID: b6c32a38-f79f06d000001a72-42-58bf12de4680 Subject: Re: counting file descriptors with a cgroup controller To: Tejun Heo Cc: lizefan@huawei.com, hannes@cmpxchg.org, =?UTF-8?Q?=c5=81ukasz_Stelmach?= , linux-kernel@vger.kernel.org, Karol Lewandowski , cgroups@vger.kernel.org From: Krzysztof Opasiak Message-id: <9ee62e45-6645-454b-11b5-85be746bc81a@samsung.com> Date: Tue, 07 Mar 2017 21:06:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-version: 1.0 In-reply-to: <20170307194134.GE31179@htj.duckdns.org> Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsWy7bCmnu49of0RBocvG1ncWD6DxWL1Jl+L xk9zmS1uHlrBaHF51xw2i0kdvewWv5YfZXRg9zj85j2zR8uRt6wem1Z1snn0bVnF6PF5k1wA axSXTUpqTmZZapG+XQJXxvS529gLXgpWTNqxjrGBcRFfFyMnh4SAicS8F9PZIWwxiQv31rN1 MXJxCAnsYJTYf301O4TTziSx5upmZpiOKd//QyWWM0qsPPgXquU+o8SUxq0sIFXCAvYS588d BLNFBGQlrkx7yAhSxCxwjlFi7b9VQO0cHGwC+hLzdomC1PAK2Em0ff0KVs8ioCqx8O0dJpAS UYEIif4z6hAlghI/Jt8DK+EUMJW4uHMSI4jNLOAo8WDRTlYIW15i85q3UIeuYpeYdssfZIwE 0AmbDkCFXST+Lj0PZQtLvDq+Bep7aYlV/24xgVwpIdDMKNGx5xkLhDOBUWLbukNQVdYSf1ZN ZINYxifx7msPK8QCXomONiGIEg+JyxM2s0DYjhKr/81hgYTPcSaJ1Wsns0xglJ+F5J9ZSH6Y heSHBYzMqxjFUguKc9NTiw0LTPSKE3OLS/PS9ZLzczcxglOKlsUOxj3nfA4xCnAwKvHwepzd FyHEmlhWXJl7iFGCg1lJhPc16/4IId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rysBhMjhATSE0tS s1NTC1KLYLJMHJxSDYyKN78a/620Pv9C60RE0/KXFcc+W69i33ph/1TdI7y5BzcfneggMdVa 68y/6UlxKcu41lgmPe5Lzj238p/4e6OpO4/HLef23zYzMz/9X0JURnNHdscn1QWW9pM383ft 6n/RL7O7pmlJhOET1/Di1vZwhjuryhiLnS/U26jvqpWsuhXdwL5k1X4lluKMREMt5qLiRADQ WumpJQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsVy+t9jAd27QvsjDL4d0rK4sXwGi8XqTb4W jZ/mMlvcPLSC0eLyrjlsFpM6etktfi0/yujA7nH4zXtmj5Yjb1k9Nq3qZPPo27KK0ePzJrkA 1ig3m4zUxJTUIoXUvOT8lMy8dFul0BA3XQslhbzE3FRbpQhd35AgJYWyxJxSIM/IAA04OAe4 Byvp2yW4ZUyfu4294KVgxaQd6xgbGBfxdTFyckgImEhM+f6fHcIWk7hwbz1bFyMXh5DAUkaJ 1slvmSGch4wST3vbwaqEBewlzp87yAJiiwjISlyZ9pARougkk8SJVztZQRxmgQuMEjv/LwVq 5+BgE9CXmLdLFKSBV8BOou3rV7BmFgFViYVv7zCB2KICERK3HnawQNQISvyYfA/M5hQwlbi4 cxIjiM0sYCux4P06FghbXmLzmrfMExgFZiFpmYWkbBaSsgWMzKsYJVILkguKk9JzDfNSy/WK E3OLS/PS9ZLzczcxgqPsmdQOxoO73A8xCnAwKvHwfji1L0KINbGsuDL3EKMEB7OSCO9r1v0R QrwpiZVVqUX58UWlOanFhxhNgR6ZyCwlmpwPTAB5JfGGJuYm5sYGFuaWliZGSuK8jbOfhQsJ pCeWpGanphakFsH0MXFwSjUwRml/iol2/Jn84q7d49Dl/Rorbk3Macvtv/l4dcUlC5aCeR/O K3992v3Eds6BvV5/57/3rnmgcDHV6GNeDov2ifb4gkLB01dEdk9hED0u7vS6nEXrt8nNeT+W vFbs8fJll6i56bz/McNulsCu2bLPj2gu+vinw23VurWCtrYBAu0fy2Lev9q6RYmlOCPRUIu5 qDgRANV7ZU3IAgAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170307200653epcas1p46ba03573f6810bbb3a8203dc08e5e789 X-Msg-Generator: CA X-Sender-IP: 203.254.230.26 X-Local-Sender: =?UTF-8?B?S3J6eXN6dG9mIE9wYXNpYWsbU1JQT0wtU3lzdGVtIChUUCkb?= =?UTF-8?B?7IK87ISx7KCE7J6QG1NvZnR3YXJlIEVuZ2luZWVy?= X-Global-Sender: =?UTF-8?B?S3J6eXN6dG9mIE9wYXNpYWsbU1JQT0wtU3lzdGVtIChUUCkb?= =?UTF-8?B?U2Ftc3VuZ8KgRWxlY3Ryb25pY3MbU29mdHdhcmUgRW5naW5lZXI=?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDAyQ0QwMjczOTY=?= CMS-TYPE: 101P X-HopCount: 7 X-CMS-RootMailID: 20170217093725eucas1p12478baf297d25303f3020f4973fbf3b0 X-RootMTR: 20170217093725eucas1p12478baf297d25303f3020f4973fbf3b0 References: <87poihtaya.fsf%l.stelmach@samsung.com> <9a57890c-d9e9-5719-e155-ce1161795a02@samsung.com> <20170306185820.GA19696@htj.duckdns.org> <7fbd9c4c-76ca-4073-9afa-1ab54364ec79@samsung.com> <20170307194134.GE31179@htj.duckdns.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Krzysztof Opasiak Subject: Re: counting file descriptors with a cgroup controller Date: Tue, 07 Mar 2017 21:06:49 +0100 Message-ID: <9ee62e45-6645-454b-11b5-85be746bc81a@samsung.com> References: <87poihtaya.fsf%l.stelmach@samsung.com> <9a57890c-d9e9-5719-e155-ce1161795a02@samsung.com> <20170306185820.GA19696@htj.duckdns.org> <7fbd9c4c-76ca-4073-9afa-1ab54364ec79@samsung.com> <20170307194134.GE31179@htj.duckdns.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-reply-to: <20170307194134.GE31179-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Tejun Heo Cc: lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org, hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org, =?UTF-8?Q?=c5=81ukasz_Stelmach?= , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Karol Lewandowski , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org 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