linux-kernel - Re: [RFC 8/8] Reduce inode memory usage for systems with a high MAX

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 16 Jan 2007 12:00:30 -0800 (PST)
From:	Christoph Lameter <clameter@....com>
To:	Paul Menage <menage@...gle.com>
cc:	akpm@...l.org, linux-kernel@...r.kernel.org,
	Nick Piggin <nickpiggin@...oo.com.au>, linux-mm@...ck.org,
	Andi Kleen <ak@...e.de>, Paul Jackson <pj@....com>,
	Dave Chinner <dgc@....com>
Subject: Re: [RFC 8/8] Reduce inode memory usage for systems with a high
 MAX_NUMNODES

On Tue, 16 Jan 2007, Paul Menage wrote:

> On 1/15/07, Christoph Lameter <clameter@....com> wrote:
> > 
> > This solution may be a bit hokey. I tried other approaches but this
> > one seemed to be the simplest with the least complications. Maybe someone
> > else can come up with a better solution?
> 
> How about a 64-bit field in struct inode that's used as a bitmask if
> there are no more than 64 nodes, and a pointer to a bitmask if there
> are more than 64 nodes. The filesystems wouldn't need to be involved
> then, as the bitmap allocation could be done in the generic code.

How would we decide if there are more than 64 nodes? Runtime or compile 
time?

If done at compile time then we will end up with a pointer to an unsigned 
long for a system with <= 64 nodes. If we allocate the nodemask via 
kmalloc then we will always end up with a mininum allocation size of 64 
bytes. Then there is the slab management overhead which will increase 
overhead closer to the 128 byte wastage that we have now. So its likely 
not worth it. There are some additional complications since there is a 
need to free and allocate the nodemask during inode initialization and 
disposal.

If the decision to allocate a node mask is made at run time then it gets 
even more complex. And we still have the same troubling issues with the 
64 byte mininum allocation by the slab.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/