lkml.org 
[lkml]   [2016]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC v1 04/14] bus1: util - fixed list utility library
Hi

On Thu, Oct 27, 2016 at 2:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, October 27, 2016 2:48:46 PM CEST David Herrmann wrote:
>> On Thu, Oct 27, 2016 at 2:37 PM, Peter Zijlstra <peterz@infradead.org> wrote:
>> > On Wed, Oct 26, 2016 at 09:18:00PM +0200, David Herrmann wrote:
>> >> + e = kmalloc_array(sizeof(*e), BUS1_FLIST_BATCH + 1, gfp);
>> >
>> >> +#define BUS1_FLIST_BATCH (1024)
>> >
>> >> +struct bus1_flist {
>> >> + union {
>> >> + struct bus1_flist *next;
>> >> + void *ptr;
>> >> + };
>> >> +};
>> >
>> > So that's an allocation of 8*(1024+1), or slightly more than 2 pages.
>> >
>> > kmalloc will round up to the next power of two, so you'll end up with an
>> > allocation of 16*1024, wasting a whopping 8184 bytes per such allocation
>> > in slack space.
>> >
>> > Please consider using 1023 or something for your batch size, 511 would
>> > get you to exactly 1 page which would be even better.
>>
>> Thanks for the hint! 511 looks like the obvious choice. Maybe even
>> (PAGE_SIZE / sizeof(long) - 1). I will put a comment next to the
>> definition.
>>
>>
>
> PAGE_SIZE can be up to 64KB though, so that might lead wasting a lot
> of memory.

The bus1-flist implementation never over-allocates. It is a fixed size
list, so it only allocates as much memory as needed. The issue PeterZ
pointed out is passing suitable sizes to kmalloc(), which internally
over-allocates to power-of-2 bounds (or some similar bounds). So we
only ever waste space here if kmalloc() internally rounds up. The code
in bus1-flist allocates exactly the needed space.

Thanks
David

\
 
 \ /
  Last update: 2016-10-27 15:50    [W:0.063 / U:0.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site