Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936153AbcCQUEH (ORCPT ); Thu, 17 Mar 2016 16:04:07 -0400 Received: from mail-wm0-f42.google.com ([74.125.82.42]:33590 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932085AbcCQUEE (ORCPT ); Thu, 17 Mar 2016 16:04:04 -0400 MIME-Version: 1.0 In-Reply-To: <20160316204002.GG21104@mtj.duckdns.org> References: <1456859137-13646-1-git-send-email-pandit.parav@gmail.com> <1456859137-13646-2-git-send-email-pandit.parav@gmail.com> <20160302173949.GG29826@mtj.duckdns.org> <20160305125215.GC3567@htj.duckdns.org> <20160316204002.GG21104@mtj.duckdns.org> Date: Fri, 18 Mar 2016 01:34:01 +0530 Message-ID: Subject: Re: [PATCHv9 1/3] rdmacg: Added rdma cgroup controller From: Parav Pandit To: Tejun Heo Cc: cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, lizefan@huawei.com, Johannes Weiner , Doug Ledford , Liran Liss , "Hefty, Sean" , Jason Gunthorpe , Haggai Eran , Jonathan Corbet , james.l.morris@oracle.com, serge@hallyn.com, Or Gerlitz , Matan Barak , 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 Content-Length: 1086 Lines: 30 Hi Tejun, On Thu, Mar 17, 2016 at 2:10 AM, Tejun Heo wrote: > >> If this is ok. I will keep the code as it is, because it uses common >> helper functions for max and current files. > > Hmmm... can you please try to refactor the common part to helpers? > It's not a big thing but there were both styles across different > controllers and helper based ones tend to be easier to follow. > in this v9 patch, To read max and current value, entry point is common function rdmacg_resource_read(). This is due to the fact that reading max and current needs to do same thing. Exceptions are taken care in below helper functions. It uses two small helper functions 1. get_cg_rpool_values 2. print_rpool_values Can I continue with this approach? > I see, but if that's the case, please drop the fine locking. The fine > locking doesn't make much sense - as implemented it's slower and the > whole thing is not hot. o.k. Also can you please confirm that once patch looks good to you, you are ok to merge this patch from Doug's linux-rdma tree as merge is clean from that tree?