* Fwd: Inoffensive bug in mm/page_alloc.c
[not found] <990119214302.n0001113.ph@mail.clara.net>
@ 1999-01-27 23:55 ` Paul Hamshere
1999-01-30 1:52 ` Benjamin C.R. LaHaise
0 siblings, 1 reply; 2+ messages in thread
From: Paul Hamshere @ 1999-01-27 23:55 UTC (permalink / raw
To: Linux-MM
Is this of any interest here?
Paul
------------------------------
Hi
I was trawling through the mm sources to try and understand how linux tracks the
use of pages of memory, how kmalloc and vmalloc work, and I think there is a bug
in the kernel (2.0) - it doesn't affect anything, only waste a tiny amount of
memory....does anyone else think it looks wrong?
The problem is in free_area_init where it allocates the bitmaps - I think they
are twice the size they need to be.
The dodgy line is
bitmap_size = (end_mem - PAGE_OFFSET) >> (PAGE_SHIFT + i );
which I think should be
bitmap_size = (end_mem - PAGE_OFFSET) >> (PAGE_SHIFT + i + 1);
because the bitmap refers to adjacent pages.
I've changed my kernel to the second line and it seems to work.
Paul
----------------------------------------------------
unsigned long free_area_init(unsigned long start_mem, unsigned long end_mem)
{
mem_map_t * p;
unsigned long mask = PAGE_MASK;
int i;
/*
* select nr of pages we try to keep free for important stuff
* with a minimum of 48 pages. This is totally arbitrary
*/
i = (end_mem - PAGE_OFFSET) >> (PAGE_SHIFT+7);
if (i < 24)
i = 24;
i += 24; /* The limit for buffer pages in __get_free_pages is
* decreased by 12+(i>>3) */
min_free_pages = i;
free_pages_low = i + (i>>1);
free_pages_high = i + i;
start_mem = init_swap_cache(start_mem, end_mem);
mem_map = (mem_map_t *) start_mem;
p = mem_map + MAP_NR(end_mem);
start_mem = LONG_ALIGN((unsigned long) p);
memset(mem_map, 0, start_mem - (unsigned long) mem_map);
do {
--p;
p->flags = (1 << PG_DMA) | (1 << PG_reserved);
p->map_nr = p - mem_map;
} while (p > mem_map);
for (i = 0 ; i < NR_MEM_LISTS ; i++) {
unsigned long bitmap_size;
init_mem_queue(free_area+i);
mask += mask;
end_mem = (end_mem + ~mask) & mask;
/* commented out because not correct ?? PH
bitmap_size = (end_mem - PAGE_OFFSET) >> (PAGE_SHIFT + i);
*/
bitmap_size = (end_mem - PAGE_OFFSET) >> (PAGE_SHIFT + i +1);
bitmap_size = (bitmap_size + 7) >> 3;
bitmap_size = LONG_ALIGN(bitmap_size);
free_area[i].map = (unsigned int *) start_mem;
memset((void *) start_mem, 0, bitmap_size);
start_mem += bitmap_size;
}
return start_mem;
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Fwd: Inoffensive bug in mm/page_alloc.c
1999-01-27 23:55 ` Fwd: Inoffensive bug in mm/page_alloc.c Paul Hamshere
@ 1999-01-30 1:52 ` Benjamin C.R. LaHaise
0 siblings, 0 replies; 2+ messages in thread
From: Benjamin C.R. LaHaise @ 1999-01-30 1:52 UTC (permalink / raw
To: Paul Hamshere; +Cc: Linux-MM
Hello Paul,
> Is this of any interest here?
Yep!
> Paul
> ------------------------------
> Hi
> I was trawling through the mm sources to try and understand how linux tracks the
> use of pages of memory, how kmalloc and vmalloc work, and I think there is a bug
> in the kernel (2.0) - it doesn't affect anything, only waste a tiny amount of
> memory....does anyone else think it looks wrong?
> The problem is in free_area_init where it allocates the bitmaps - I think they
> are twice the size they need to be.
If you search the mailing list archives from either a year, maybe two ago,
someone brought forth the same concern, but Linus rejected the patch on
the basis that it wasn't trivially proven correct for *all* sizes of
memory. The amount of memory involved is insignificant, and I'd speculate
that we'll see a page allocator in 2.3 at which point that loss can
disappear.
-ben (cleaning out the inbox)
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1999-01-30 1:53 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <990119214302.n0001113.ph@mail.clara.net>
1999-01-27 23:55 ` Fwd: Inoffensive bug in mm/page_alloc.c Paul Hamshere
1999-01-30 1:52 ` Benjamin C.R. LaHaise
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).