On Fri, Feb 13, 2009 at 8:20 AM, Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote: > On Friday 13 February 2009 10:37:01 Matt Mackall wrote: >> On Fri, 2009-02-13 at 07:09 +0800, Herbert Xu wrote: >> > On Fri, Feb 13, 2009 at 12:10:45AM +1100, Nick Piggin wrote: >> > > I would be interested to know how that goes. You always have this >> > > circular issue that if a little more space helps significantly, then >> > > maybe it is a good idea to explicitly ask for those bytes. Of course >> > > that larger allocation is also likely to have some slack bytes. >> > >> > Well, the thing is we don't know apriori whether we need the >> > extra space. The idea is to use the extra space if available >> > to avoid reallocation when we hit things like IPsec. >> >> I'm not entirely convinced by this argument. If you're concerned about >> space rather than performance, then you want an allocator that doesn't >> waste space in the first place and you don't try to do "sub-allocations" >> by hand. If you're concerned about performance, you instead optimize >> your allocator to be as fast as possible and again avoid conditional >> branches for sub-allocations. > > Well, my earlier reasoning is no longer so clear cut if eg. there > are common cases where no extra space is required, but rare cases > where extra space might be a big win if it eg avoids extra > alloc, copy, free or something. > > Because even with performance oriented allocators, there is a non-zero > cost to explicitly asking for more memory -- queues tend to get smaller > at larger object sizes, and page allocation orders can increase. So if > it is very uncommon to need extra space you don't want to burden the > common case with it. My concern would be that such extra-space reuse would be a very non-obvious performance hit if allocation patterns changed slightly. If being able to use the extra space really is a noticeable "big win" for the rare case, then minor changes to the memory allocator could dramatically impact performance in a totally nondeterministic way. If the change isn't performance-significant in the grand scheme of things, then the use of ksize() would just be code obfuscation. On the other hand if it *is* performance-significant, it should be redesigned to be able to guarantee that the space is available when it is needed. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
