Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752972AbbF3V0y (ORCPT ); Tue, 30 Jun 2015 17:26:54 -0400 Received: from mga11.intel.com ([192.55.52.93]:39759 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752597AbbF3V0q convert rfc822-to-8bit (ORCPT ); Tue, 30 Jun 2015 17:26:46 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,380,1432623600"; d="scan'208";a="756088842" From: "Dilger, Andreas" To: Julia Lawall CC: "devel@driverdev.osuosl.org" , "Greg Kroah-Hartman" , "kernel-janitors@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Drokin, Oleg" , "lustre-devel@lists.lustre.org" Subject: Re: [lustre-devel] LIBCFS_ALLOC Thread-Topic: [lustre-devel] LIBCFS_ALLOC Thread-Index: AQHQsW8PiY3YDMme302N3vPVpksnTJ3FpNEA Date: Tue, 30 Jun 2015 21:26:43 +0000 Message-ID: References: <1434819550-3193-1-git-send-email-Julia.Lawall@lip6.fr> <1434819550-3193-2-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.254.77.180] Content-Type: text/plain; charset="us-ascii" Content-ID: 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 Content-Length: 2006 Lines: 53 On 2015/06/28, 12:52 AM, "Julia Lawall" wrote: >It is not clear that all of the uses of LIBCFS_ALLOC really risk needing >vmalloc. For example: > >lnet/klnds/socklnd/socklnd.c, function ksocknal_accept: > >ksock_connreq_t *cr; >... >LIBCFS_ALLOC(cr, sizeof(*cr)); > >The definition of ksock_connreq_t is: > >typedef struct ksock_connreq { > struct list_head ksncr_list; /* stash on ksnd_connd_connreqs */ > lnet_ni_t *ksncr_ni; /* chosen NI */ > struct socket *ksncr_sock; /* accepted socket */ >} ksock_connreq_t; > >This looks like a very small structure. > >LIBCFS_ALLOC relies on a test on the size, which should be able to be >compiled away. libcfs_kvzalloc on the other hand relies on the failure >of >kmalloc and so the test for that won't be compiled away. There are probably only a handful of places where trying vmalloc() even makes sense. In most cases, LIBCFS_ALLOC() can be replaced by a straight call to kmalloc() because the allocation size is small enough, and only a few need to use libcfs_kvzalloc(). Anything at PAGE_SIZE or less will either work with kmalloc() or it won't work at all. I do agree with James' comments that vmalloc() was needed for both very large allocations that can't be satisfied by kmalloc() at all, as well as smaller allocations (anything over a couple of pages) due to fragmentation of free pages after running for a long time. I think libcfs_kvzalloc() is at least as good as the size-based threshold used previously, since using kmalloc() is going to be faster than vmalloc() and would work better on 32-bit platforms with limited vmalloc() size. Cheers, Andreas -- Andreas Dilger Lustre Software Architect Intel High Performance Data Division -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/