[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200705201456.26283.ak@suse.de>
Date: Sun, 20 May 2007 14:56:25 +0200
From: Andi Kleen <ak@...e.de>
To: Eric Dumazet <dada1@...mosbay.com>
Cc: Christoph Lameter <clameter@....com>,
William Lee Irwin III <wli@...omorphy.com>,
Nick Piggin <npiggin@...e.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Memory Management List <linux-mm@...ck.org>,
linux-arch@...r.kernel.org
Subject: Re: [rfc] increase struct page size?!
On Sunday 20 May 2007 06:10:16 Eric Dumazet wrote:
> Christoph Lameter a écrit :
> > On Sat, 19 May 2007, William Lee Irwin III wrote:
> >
> >> However, there are numerous optimizations and features made possible
> >> with flag bits, which might as could be made cheap by padding struct
> >> page up to the next highest power of 2 bytes with space for flag bits.
> >
> > Well the last time I tried to get this by Andi we became a bit concerned
> > when we realized that the memory map would grow by 14% in size. Given
> > that 4k page size challenged platforms have a huge amount of page structs
> > that growth is significant. I think it would be fine to do it for IA64
> > with 16k page size but not for x86_64.
>
> This reminds me Andi attempted in the past to convert 'flags' to a 32 bits field :
>
> http://marc.info/?l=linux-kernel&m=107903527523739&w=2
>
> I wonder why this idea was not taken, saving 2MB per GB of memory is nice :)
It made sense in 2.4, but in 2.6 it doesn't actually save any memory because
there is no field to put into the freed padding.
Besides with the scarcity of pageflags it might make sense to do "64 bit only"
flags at some point.
-Andi
-
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/
Powered by blists - more mailing lists