> To allocate large memory which requires several pages, is not > preferable. If kmalloc() in linux kernel supports several 128kb(for 32bit) > or 256kb(for 64bit) allocations, you can enable MAX_32767 in safe. > Actually, I don't know the exact limit of kmalloc. (I've heared it > support upto 128kb).
I heard too, and I heard vmalloc can be used to allocate more (as Jan suggested). > Additonally, I didn't think over 1024 branches is > important. So I left this issue alone. If you really need such large > branches, it is worth to rewrite branch management code to call kernel > function other than kmalloc(). In fact, I don't really need it that much. 1024 is enough for me today. But every limit is bad, in general... and moreover if the limit is only caused by the used function to allocate memory (kmalloc here), then there must be a way to rewrite it better :) > By the way, I've found one issue while I was refering to the source code > to write this mail. Introducing CONFIG_AUFS_HINOTIFY and other features, > the element of an array becomes a larger object than a pointer. So the > array will be larger than a page at most. Well, it still works, even with larger objects than a page :) Tomas M ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
