On Fri, 7 Dec 2012 01:09:27 +0900 Joonsoo Kim <js1304@xxxxxxxxx> wrote: > This patchset remove vm_struct list management after initializing vmalloc. > Adding and removing an entry to vmlist is linear time complexity, so > it is inefficient. If we maintain this list, overall time complexity of > adding and removing area to vmalloc space is O(N), although we use > rbtree for finding vacant place and it's time complexity is just O(logN). > > And vmlist and vmlist_lock is used many places of outside of vmalloc.c. > It is preferable that we hide this raw data structure and provide > well-defined function for supporting them, because it makes that they > cannot mistake when manipulating theses structure and it makes us easily > maintain vmalloc layer. > > I'm not sure that "7/8: makes vmlist only for kexec" is fine. > Because it is related to userspace program. > As far as I know, makedumpfile use kexec's output information and it only > need first address of vmalloc layer. So my implementation reflect this > fact, but I'm not sure. And now, I don't fully test this patchset. > Basic operation work well, but I don't test kexec. So I send this > patchset with 'RFC'. > > Please let me know what I am missing. > > This series based on v3.7-rc7 and on top of submitted patchset for ARM. > 'introduce static_vm for ARM-specific static mapped area' > https://lkml.org/lkml/2012/11/27/356 > But, running properly on x86 without ARM patchset. This all looks rather nice, but not mergeable into anything at this stage in the release cycle. What are the implications of "on top of submitted patchset for ARM"? Does it depens on the ARM patches in any way, or it it independently mergeable and testable? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>