[lkml]   [2001]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] bootmem for 2.5
On Fri, Nov 02, 2001 at 02:02:07PM -0800, William Irwin wrote:
>> The following patch features space usage proportional only to the number
>> of distinct fragments of memory, tracking available memory at address
>> granularity up until the point of initializing per-page data structures,
>> and the use of segment trees in order to support efficient searches on
>> those rare machines where this is an issue. According to testing, this
>> patch appears to save somewhere between 8KB and 2MB on i386 PC's versus
>> the bitmap-based bootmem allocator.

On Fri, Nov 02, 2001 at 09:43:08PM -0800, Greg KH wrote:
> How will I see the difference in memory available between your patch and
> the in kernel version? Can it be seen by merely comparing free(1)
> values?

Not sure what ate my original reply, so here I go again.

Yes, it will be visible in free(1) and dmesg. The amount of available
physical memory will be increased. For the most part because of the
ability of the stock bootmem to merge sub-page allocations while
otherwise tracking things at page granularity (using bdata->last_offset)
is limited. On the other hand, I track things at address granularity and
so achieve a "tightest packing" regardless of the order in which
allocations are done.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:12    [W:0.120 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site