Christoph> Hey, I didn't mean _always_ build out of the box :) I'm
Christoph> much more looking forward to 2.6.x releases I'd like to
Christoph> see just build for ia64.
That's a goal I share. But I won't reach it without some help.
>> I'm working on) and the virtual mem_map support. The latter I
>> haven't pushed at all so far, mostly because I just haven't had
>> the time/energy/interest to do so. Also, I'm always optimistic
>> someone else comes along to help with the work... ;-)
Christoph> Well, I could try to help pushing some stuff. OTOH
Christoph> pushing stuff I don't understand is a bad idea.
That's true.
Christoph> Could you please explain e.g. the mm/bootmem.c and
Christoph> mm/page_alloc.c changes?
The bootmem patch is a performance speed up and some minor indendation
fixups. The problem was that the bootmem code was (a) hugely slow and
(b) had execution that grew quadratically with the size of the bootmap
bitmap. This causes noticable slowdowns, especially on machines with
(relatively) large holes in the physical memory map. Issue (b) is
addressed by maintaining the "last_success" cache, so that we start
the next search from the place where we last found some memory (this
part of the patch could stand additional reviewing/testing). Issue
(a) is addressed by using find_next_zero_bit() instead of the slow
bit-by-bit testing.
The page_alloc.c changes are in support of virtual mem_map: it needs
an architecture-specific hook when initializing the mem_map. The
patch should be safe for arches that don't use virtual mem_map.
--david
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/