From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx193.postini.com [74.125.245.193]) by kanga.kvack.org (Postfix) with SMTP id 088F16B0068 for ; Wed, 19 Dec 2012 21:25:38 -0500 (EST) Message-ID: <50D27707.7060309@oracle.com> Date: Wed, 19 Dec 2012 21:25:11 -0500 From: Sasha Levin MIME-Version: 1.0 Subject: Re: [PATCH 04/15] mm/huge_memory: use new hashtable implementation References: <1355756497-15834-1-git-send-email-sasha.levin@oracle.com> <1355756497-15834-4-git-send-email-sasha.levin@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes Cc: Andrew Morton , "Kirill A. Shutemov" , Xiao Guangrong , Andrea Arcangeli , linux-mm@kvack.org, linux-kernel@vger.kernel.org On 12/19/2012 05:26 PM, David Rientjes wrote: > This used to be dynamically allocated and would save the 8KB that you > statically allocate if transparent hugepages cannot be used. The generic > hashtable implementation does not support dynamic allocation? No, currently the hashtable only handles statically allocated hashtables. In this case, the downside is that you'll waste 8KB if hugepages aren't available, but the upside is that you'll have one less dereference when accessing the hashtable. If the 8KB saving is preferable here I'll drop the patch and come back when dynamic hashtable is supported. Thanks, Sasha -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752428Ab2LTCZu (ORCPT ); Wed, 19 Dec 2012 21:25:50 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:42269 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752115Ab2LTCZn (ORCPT ); Wed, 19 Dec 2012 21:25:43 -0500 Message-ID: <50D27707.7060309@oracle.com> Date: Wed, 19 Dec 2012 21:25:11 -0500 From: Sasha Levin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: David Rientjes CC: Andrew Morton , "Kirill A. Shutemov" , Xiao Guangrong , Andrea Arcangeli , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 04/15] mm/huge_memory: use new hashtable implementation References: <1355756497-15834-1-git-send-email-sasha.levin@oracle.com> <1355756497-15834-4-git-send-email-sasha.levin@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/19/2012 05:26 PM, David Rientjes wrote: > This used to be dynamically allocated and would save the 8KB that you > statically allocate if transparent hugepages cannot be used. The generic > hashtable implementation does not support dynamic allocation? No, currently the hashtable only handles statically allocated hashtables. In this case, the downside is that you'll waste 8KB if hugepages aren't available, but the upside is that you'll have one less dereference when accessing the hashtable. If the 8KB saving is preferable here I'll drop the patch and come back when dynamic hashtable is supported. Thanks, Sasha