Re: [PATCH 04/15] mm/huge_memory: use new hashtable implementation

2012-12-20 Thread Sasha Levin
On 12/20/2012 03:28 PM, David Rientjes wrote: > On Wed, 19 Dec 2012, Sasha Levin wrote: > >> 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

Re: [PATCH 04/15] mm/huge_memory: use new hashtable implementation

2012-12-20 Thread David Rientjes
On Wed, 19 Dec 2012, Sasha Levin wrote: > 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

Re: [PATCH 04/15] mm/huge_memory: use new hashtable implementation

2012-12-19 Thread Sasha Levin
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 handl

Re: [PATCH 04/15] mm/huge_memory: use new hashtable implementation

2012-12-19 Thread David Rientjes
On Mon, 17 Dec 2012, Sasha Levin wrote: > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 827d9c8..2a0ef01 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -20,6 +20,7 @@ > #include > #include > > +#include > #include > #include > #include "internal.h" Why group

[PATCH 04/15] mm/huge_memory: use new hashtable implementation

2012-12-17 Thread Sasha Levin
Switch hugemem to use the new hashtable implementation. This reduces the amount of generic unrelated code in the hugemem. This also removes the dymanic allocation of the hash table. The size of the table is constant so there's no point in paying the price of an extra dereference when accessing i