2014-11-14 15:17+0100, Igor Mammedov: > > (We'll have to change it into an interval tree, or something, if the > > number of slots rises anyway.) > Only if it rises to huge amount, I've played with proposed 512 memslots > and it takes ~10000 cycles which is 5% of current heapsort overhead. > Taking in account that it's slow path anyway, it's unlikely that there > would be need to speedup this case even more.
Yes, your improvement is great and would work even for higher amounts. I meant that our lookup is currently pretty sad -- O(N) that is presumably optimized by looking at the largest regions first. Maybe we would benefit from O(log N) lookup even with 128 memslots. -- 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/
