From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752037AbbECKaC (ORCPT ); Sun, 3 May 2015 06:30:02 -0400 Received: from mga03.intel.com ([134.134.136.65]:52597 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751169AbbECK35 convert rfc822-to-8bit (ORCPT ); Sun, 3 May 2015 06:29:57 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,359,1427785200"; d="scan'208";a="488690174" From: "Drokin, Oleg" To: Julia Lawall CC: "" , "Dilger, Andreas" , Greg Kroah-Hartman , "" , "" , "" Subject: Re: [PATCH] staging: lustre: obd_support: Add obd_cpt_alloc function Thread-Topic: [PATCH] staging: lustre: obd_support: Add obd_cpt_alloc function Thread-Index: AQHQhR6Csy2fZNSzs0Omjdfvycz9WZ1pwKWcgADCpYA= Date: Sun, 3 May 2015 10:29:54 +0000 Message-ID: References: <1430601408-12847-1-git-send-email-Julia.Lawall@lip6.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.196.182] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7998732EA4B058419A11F032558F59E4@intel.com> Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On May 3, 2015, at 1:53 AM, Julia Lawall wrote: > On Sat, 2 May 2015, Drokin, Oleg wrote: > >> >> On May 2, 2015, at 5:16 PM, Julia Lawall wrote: >> >>> Summarize OBD_CPT_ALLOC_GFP, OBD_CPT_ALLOC, and OBD_CPT_ALLOC_PTR as a >>> function, obd_cpt_alloc. >>> >>> Signed-off-by: Julia Lawall >>> >>> --- >>> >>> Some questions: Is the name OK? Is the NULL test needed? If not, should >>> the call to kzalloc_node with the call to cfs_cpt_spread_node just be >>> inlined into the call sites? >> >> I think we don't need this function at all, we can use kzalloc/kzalloc_node directly with cfs_cpt_spread_node call in. > > So everywhere the CPT macro is called, it is known that the value is not > NULL? I looked at some call sites, but it's not obvious to determine > that. It's not obvious, but I believe this is true now. Basically in lustre/ptlrpc/service.c we use service->srv_cptable and that comes from ptlrpc_register_service: cptable = cconf->cc_cptable; if (cptable == NULL) cptable = cfs_cpt_table; …. service->srv_cptable = cptable; service->srv_cpts = cpts; service->srv_ncpts = ncpts; that on the client it's only called from: lustre/ldlm/ldlm_lockd.c::ldlm_setup() where we unconditionally assign .psc_cpt = { .cc_pattern = ldlm_cpts, }, But even if there was a different caller, we always use cfs_cpt_table as fallback. It's also directly used in ptlrpc_hr_init(): ptlrpc_hr.hr_cpt_table = cfs_cpt_table; Two callers in lustre/ptlrpc/nrs.c use the same stuff as above. One caller in lustre/ptlrpc/nrs_fifo.c uses nrs_pol2cptab which is defined as nrs_pol2svc(policy)->srv_cptable which is again same as above. There are no other callers. Bye, Oleg