* Andrea Arcangeli ([EMAIL PROTECTED]) wrote: > The object of the merge is to save memory, and to reduce the size of the > rbtree that might payoff during other operations (with a smaller tree, > lookups will be faster too). If you only measure the time of creating > and removing a mapping then it should be normal that you see a slowdown > since merging involves more work than non-merging. The payoff is > supposed to be in the other operations.
I agree, that test is pathological worst case. > The reason mlock doesn't merge is that nobody asked for it yet, but it > was originally supposed to merge too (I stopped at mremap since mlock > wasn't high prio to fixup). But the long term plan was to eventually add > merging to mlock too and it's good that you're optimizing it now. Do you support merging this patch? Or did you mean further optimizations? thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
