Re: [PATCH] Export symbol ksize()

[Kyle Moffett]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/