On 05/15/2012 11:25 PM, Andrew Morton wrote: > On Tue, 15 May 2012 11:02:17 +0300 > Avi Kivity <avi@xxxxxxxxxx> wrote: > > > On 05/14/2012 04:29 PM, Takuya Yoshikawa wrote: > > > On Sun, 13 May 2012 13:20:46 +0300 > > > Avi Kivity <avi@xxxxxxxxxx> wrote: > > > > > > > I don't feel that the savings is worth the extra complication. We save > > > > two pages per memslot here. > > > > > > Using a 4KB vmalloced page for a 16B array is ... > > > > > > Actually I felt like you before and did not do this, but recently there > > > was a talk about creating hundreds of memslots. > > > > > > > What about using kvmalloc() instead of vmalloc()? It's in > > > > security/apparmor now, but can be made generic. > > > > > > Andrew once, maybe some times, rejected making such an API generic saying > > > that there should not be a generic criterion by which we can decide which > > > function - vmalloc() or kmalloc() - to use. > > > > > > So each caller should decide by its own criteria. > > > > > > In this case, we need to implement kvm specific kvmalloc(). > > > BTW, we are already doing this for dirty_bitmap. > > > > Okay, a local kvmalloc() is better than open-coding the logic. > > > > Andrew, prepare yourself for some code duplication. > > There are reasons for avoiding vmalloc(). > > The kernel does not run in a virtual memory environment. It is a > harsh, low-level environment and kernel code should be robust. This is about downgrading an existing vmalloc() to kmalloc(), when the sizes permit, to reduce wastage. Not about upgrading a kmalloc() to vmalloc(). > Assuming that you can allocate vast amounts of contiguous memory is not > robust. Robust code will implement data structures which avoid this > weakness. This is true on some architectures. On others vast amounts of contiguous memory _are_ available, and implementing software radix trees to replace the hardware radix trees is not going to improve things. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
