Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753577AbbF3O4c (ORCPT ); Tue, 30 Jun 2015 10:56:32 -0400 Received: from mta02.ornl.gov ([128.219.177.12]:23882 "EHLO mta02.ornl.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753099AbbF3O4Y convert rfc822-to-8bit (ORCPT ); Tue, 30 Jun 2015 10:56:24 -0400 X-SG: RELAYLIST X-IronPort-AV: E=Sophos;i="5.15,378,1432612800"; d="scan'208";a="83056486" From: "Simmons, James A." To: "'Dan Carpenter'" , Julia Lawall CC: "devel@driverdev.osuosl.org" , "Dilger, Andreas" , Greg Kroah-Hartman , "kernel-janitors@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Drokin, Oleg" , "lustre-devel@lists.lustre.org" Subject: RE: LIBCFS_ALLOC Thread-Topic: LIBCFS_ALLOC Thread-Index: AQHQsez8S3Vue9VDskyW8uncIc4Iup3FIaqA Date: Tue, 30 Jun 2015 14:56:21 +0000 Message-ID: References: <1434819550-3193-1-git-send-email-Julia.Lawall@lip6.fr> <1434819550-3193-2-git-send-email-Julia.Lawall@lip6.fr> <20150628215408.GG28762@mwanda> In-Reply-To: <20150628215408.GG28762@mwanda> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.219.12.132] Content-Type: text/plain; charset="us-ascii" 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: 1057 Lines: 17 >Yeah. You're right. Doing a vmalloc() when kmalloc() doesn't have even >a tiny sliver of RAM isn't going to work. It's easier to use >libcfs_kvzalloc() everywhere, but it's probably the wrong thing. The original reason we have the vmalloc water mark wasn't so much the issue of memory exhaustion but to handle the case of memory fragmentation. Some sites had after a extended period of time started to see failures of allocating even 32K using kmalloc. In our latest development branch we moved away from using a water mark to always try kmalloc first and if it fails then we try vmalloc. At ORNL we ran into severe performance issues when we entered vmalloc territory. It has been discussed before on what might replace vmalloc handling in the case of kmalloc fails but no solution has been worked out. -- 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/