From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753001AbbIKQjx (ORCPT ); Fri, 11 Sep 2015 12:39:53 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:35658 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751532AbbIKQju (ORCPT ); Fri, 11 Sep 2015 12:39:50 -0400 MIME-Version: 1.0 In-Reply-To: <20150911163449.GS8114@mtj.duckdns.org> References: <20150908152340.GA13749@mtj.duckdns.org> <20150910164946.GH8114@mtj.duckdns.org> <20150910202210.GL8114@mtj.duckdns.org> <20150911040413.GA18850@htj.duckdns.org> <55F25781.20308@redhat.com> <20150911145213.GQ8114@mtj.duckdns.org> <20150911163449.GS8114@mtj.duckdns.org> Date: Fri, 11 Sep 2015 22:09:48 +0530 Message-ID: Subject: Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource From: Parav Pandit To: Tejun Heo Cc: Doug Ledford , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, lizefan@huawei.com, Johannes Weiner , Jonathan Corbet , james.l.morris@oracle.com, serge@hallyn.com, Haggai Eran , Or Gerlitz , Matan Barak , raindel@mellanox.com, akpm@linux-foundation.org, linux-security-module@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 11, 2015 at 10:04 PM, Tejun Heo wrote: > Hello, Parav. > > On Fri, Sep 11, 2015 at 09:56:31PM +0530, Parav Pandit wrote: >> Resource run away by application can lead to (a) kernel and (b) other >> applications left out with no resources situation. > > Yeap, that this controller would be able to prevent to a reasonable > extent. > >> Both the problems are the target of this patch set by accounting via cgroup. >> >> Performance contention can be resolved with higher level user space, >> which will tune it. > > If individual applications are gonna be allowed to do that, what's to > prevent them from jacking up their limits? I should have been more explicit. I didnt mean the application to control which is allocating it. > So, I assume you're > thinking of a central authority overseeing distribution and enforcing > the policy through cgroups? > Exactly. >> Threshold and fail counters are on the way in follow on patch. > > If you're planning on following what the existing memcg did in this > area, it's unlikely to go well. Would you mind sharing what you have > on mind in the long term? Where do you see this going? > At least current thoughts are: central entity authority monitors fail count and new threashold count. Fail count - as similar to other indicates how many time resource failure occured threshold count - indicates upto what this resource has gone upto in usage. (application might not be able to poll on thousands of such resources entries). So based on fail count and threshold count, it can tune it further. > Thanks. > > -- > tejun From mboxrd@z Thu Jan 1 00:00:00 1970 From: Parav Pandit Subject: Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource Date: Fri, 11 Sep 2015 22:09:48 +0530 Message-ID: References: <20150908152340.GA13749@mtj.duckdns.org> <20150910164946.GH8114@mtj.duckdns.org> <20150910202210.GL8114@mtj.duckdns.org> <20150911040413.GA18850@htj.duckdns.org> <55F25781.20308@redhat.com> <20150911145213.GQ8114@mtj.duckdns.org> <20150911163449.GS8114@mtj.duckdns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20150911163449.GS8114-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Tejun Heo Cc: Doug Ledford , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org, Johannes Weiner , Jonathan Corbet , james.l.morris-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org, Haggai Eran , Or Gerlitz , Matan Barak , raindel-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-rdma@vger.kernel.org On Fri, Sep 11, 2015 at 10:04 PM, Tejun Heo wrote: > Hello, Parav. > > On Fri, Sep 11, 2015 at 09:56:31PM +0530, Parav Pandit wrote: >> Resource run away by application can lead to (a) kernel and (b) other >> applications left out with no resources situation. > > Yeap, that this controller would be able to prevent to a reasonable > extent. > >> Both the problems are the target of this patch set by accounting via cgroup. >> >> Performance contention can be resolved with higher level user space, >> which will tune it. > > If individual applications are gonna be allowed to do that, what's to > prevent them from jacking up their limits? I should have been more explicit. I didnt mean the application to control which is allocating it. > So, I assume you're > thinking of a central authority overseeing distribution and enforcing > the policy through cgroups? > Exactly. >> Threshold and fail counters are on the way in follow on patch. > > If you're planning on following what the existing memcg did in this > area, it's unlikely to go well. Would you mind sharing what you have > on mind in the long term? Where do you see this going? > At least current thoughts are: central entity authority monitors fail count and new threashold count. Fail count - as similar to other indicates how many time resource failure occured threshold count - indicates upto what this resource has gone upto in usage. (application might not be able to poll on thousands of such resources entries). So based on fail count and threshold count, it can tune it further. > Thanks. > > -- > tejun -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html