On 6/19/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote: > "Magnus Damm" <[EMAIL PROTECTED]> writes: > > On 6/8/06, Vivek Goyal <[EMAIL PROTECTED]> wrote: > >> I don't know what are the advantages of static allocation. Eric > >> can throw some light. > > > > I'd like to hear the advantages. > > It is simple because it is all constants. And it removes the > need for additional infrastructure. Which for an incremental > patch is a huge win. Allowing us to address one concern at a time.
I like the idea of one concern at a time. If the code becomes simpler or not is probably just a matter of taste. I do however know one thing: Static allocation will make the xen porting work more difficult. > > Right now I can only see the disadvantages of static allocation. If > > page_table_a is statically allocated 7/5/3 pages will be consumed on > > x86_64/i386+PAE/i386. I'd like to stay away from eating 12-28 Kbytes > > of kernel memory statically (= at boot time) without any special > > reason. > > Yes. It is a measurable amount of memory. However it is not so much > that it is prohibitive, and for everyone using the feature it is not > a waste of memory :) Well, it sure is a waste of memory until the point the secondary kernel is loaded. The same amount of memory is used today by my page_table_a patches, but there is one very important difference: With my dynamic allocation strategy we are not using the memory until the secondary kernel is loaded. Your are proposing static allocation that will result in that just by enabling CONFIG_KEXEC a kernel will eat 12-28 KBytes of kernel memory. > > Let me know what you think and I will rewrite and break out the code. > > I just want a simple starting point so we can look at one issue at > a time. Once we have sorted through what we need in the trivial page > table then we can discuss changing our allocation policy of it to be dynamic. I'd like a simple starting point too. It sounds like you want to put more information in page_table_a than I do now. Any plans you'd like to share? Thanks for the comments! / magnus _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
