From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755461AbbINPVX (ORCPT ); Mon, 14 Sep 2015 11:21:23 -0400 Received: from mail-yk0-f173.google.com ([209.85.160.173]:33330 "EHLO mail-yk0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755701AbbINPVU (ORCPT ); Mon, 14 Sep 2015 11:21:20 -0400 Date: Mon, 14 Sep 2015 11:21:13 -0400 From: Tejun Heo To: Parav Pandit Cc: "Hefty, Sean" , Jason Gunthorpe , 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" Subject: Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource Message-ID: <20150914152113.GA20047@mtj.duckdns.org> References: <20150910202210.GL8114@mtj.duckdns.org> <20150911040413.GA18850@htj.duckdns.org> <55F25781.20308@redhat.com> <20150911145213.GQ8114@mtj.duckdns.org> <1828884A29C6694DAF28B7E6B8A82373A903A586@ORSMSX109.amr.corp.intel.com> <20150911194311.GA18755@obsidianresearch.com> <1828884A29C6694DAF28B7E6B8A82373A903A5DB@ORSMSX109.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Parav. On Mon, Sep 14, 2015 at 07:34:09PM +0530, Parav Pandit wrote: > I missed to acknowledge your point that we need both - hard limit and > soft limit/weight. Current patchset is only based on hard limit. > I see that weight would be another helfpul layer in chain that we can > implement after this as incremental that makes review, debugging > manageable? At this point, I'm very unsure that doing this as a cgroup controller is a good direction. From userland interface standpoint, publishing a cgroup controller is a big commitment. It is true that we haven't been doing a good job of gatekeeping or polishing controller interfaces but we're trying hard to change that and what's being proposed in this thread doesn't really seem to be mature enough. It's not even clear what's being identified as resources here are things that the users would actually care about or if it's even possible to implement sensible resource control in the kernel via the proposed resource restrictions. So, I'd suggest going back to the board and figuring out what the actual resources are, their distribution strategies should be and at which layer such strategies can be implemented best. Thanks. -- tejun From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource Date: Mon, 14 Sep 2015 11:21:13 -0400 Message-ID: <20150914152113.GA20047@mtj.duckdns.org> References: <20150910202210.GL8114@mtj.duckdns.org> <20150911040413.GA18850@htj.duckdns.org> <55F25781.20308@redhat.com> <20150911145213.GQ8114@mtj.duckdns.org> <1828884A29C6694DAF28B7E6B8A82373A903A586@ORSMSX109.amr.corp.intel.com> <20150911194311.GA18755@obsidianresearch.com> <1828884A29C6694DAF28B7E6B8A82373A903A5DB@ORSMSX109.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Parav Pandit Cc: "Hefty, Sean" , Jason Gunthorpe , 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 Hello, Parav. On Mon, Sep 14, 2015 at 07:34:09PM +0530, Parav Pandit wrote: > I missed to acknowledge your point that we need both - hard limit and > soft limit/weight. Current patchset is only based on hard limit. > I see that weight would be another helfpul layer in chain that we can > implement after this as incremental that makes review, debugging > manageable? At this point, I'm very unsure that doing this as a cgroup controller is a good direction. From userland interface standpoint, publishing a cgroup controller is a big commitment. It is true that we haven't been doing a good job of gatekeeping or polishing controller interfaces but we're trying hard to change that and what's being proposed in this thread doesn't really seem to be mature enough. It's not even clear what's being identified as resources here are things that the users would actually care about or if it's even possible to implement sensible resource control in the kernel via the proposed resource restrictions. So, I'd suggest going back to the board and figuring out what the actual resources are, their distribution strategies should be and at which layer such strategies can be implemented best. 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