vfs_acl_xattr and Linux memory fragmentation

[Uri Simchoni]

On 04/13/2017 10:33 AM, Volker Lendecke via samba-technical wrote:
> On Wed, Apr 12, 2017 at 08:09:50PM +0300, Uri Simchoni wrote:
>> About efficiency - what I've been able to discern, without going into
>> too much detail, is that:
>> a. There's no per-object overhead, you kmalloc 4K you use 4K.
>> b. There should be an advantage to allocating 4K over 64, but not
>> because it happens to be page size, but rather because it has a backing
>> pool (see  kmalloc-4096 in /proc/slabinfo). If that pool needs to
>> allocate more 4K buffers, it does so in 32K units, which is also prone
>> to fragmentation issues, but more often than not, you have 4K objects in
>> the pool. 64K allocations don't have such a pool so every time you
>> either have contiguous 64K, or you don't (and once memory becomes
>> fragmented, you normally don't).
> 
> My /proc/slabinfo also has kmalloc-2048 and kmalloc-8192. This starts
> to turn into bike-shedding, but is there any value in also trying 2k
> and 8k?
> 
> Volker
> 

My thinking was that trying 2K and 8K could very well lead to
accomplishing the task with way more than 2 system calls. There's always
the option of passing 0 as size to get actual size, then call again with
the buffer - two system calls.

But I can add those steps too - I don't have any field-gathered
information to support this or that strategy, they all have their
strengths and weaknesses (for example, maybe there are less objects in
the 8K pool, so it's likelier to be depleted with many concurrent
users). Ultimately, it's a kernel issue and has been fixed in the kernel
(don't know specifics of distros).

What I think we should keep is that the initial allocation is 1K,
because that preserves the user-mode behavior for the majority of cases.

Thanks,
Uri.