From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753501AbbIKQrr (ORCPT ); Fri, 11 Sep 2015 12:47:47 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:38273 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751514AbbIKQro (ORCPT ); Fri, 11 Sep 2015 12:47:44 -0400 MIME-Version: 1.0 In-Reply-To: <20150911145213.GQ8114@mtj.duckdns.org> References: <1441658303-18081-1-git-send-email-pandit.parav@gmail.com> <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> Date: Fri, 11 Sep 2015 22:17:42 +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 > cpuset is a special case but think of cpu, memory or io controllers. > Their resource distribution schemes are a lot more developed than > what's proposed in this patchset and that's a necessity because nobody > wants to cripple their machines for resource control. IO controller and applications are mature in nature. When IO controller throttles the IO, applications are pretty mature where if IO takes longer to complete, there is possibly almost no way to cancel the system call or rather application might not want to cancel the IO at least the non asynchronous one. So application just notice lower performance than throttled way. Its really not possible at RDMA level with RDMA resource to hold up resource creation call for longer time, because reusing existing resource with failed status can likely to give better performance. As Doug explained in his example, many RDMA resources as its been used by applications are relatively long lived. So holding ups resource creation while its taken by other process will certainly will look bad on application performance front compare to returning failure and reusing existing one once its available or once new one is available. 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:17:42 +0530 Message-ID: References: <1441658303-18081-1-git-send-email-pandit.parav@gmail.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20150911145213.GQ8114-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 > cpuset is a special case but think of cpu, memory or io controllers. > Their resource distribution schemes are a lot more developed than > what's proposed in this patchset and that's a necessity because nobody > wants to cripple their machines for resource control. IO controller and applications are mature in nature. When IO controller throttles the IO, applications are pretty mature where if IO takes longer to complete, there is possibly almost no way to cancel the system call or rather application might not want to cancel the IO at least the non asynchronous one. So application just notice lower performance than throttled way. Its really not possible at RDMA level with RDMA resource to hold up resource creation call for longer time, because reusing existing resource with failed status can likely to give better performance. As Doug explained in his example, many RDMA resources as its been used by applications are relatively long lived. So holding ups resource creation while its taken by other process will certainly will look bad on application performance front compare to returning failure and reusing existing one once its available or once new one is available. -- 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