[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cfb7c8df-2a6a-bf84-8a30-df97c58c9c47@infradead.org>
Date: Thu, 24 May 2018 11:40:59 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: Matthew Wilcox <willy@...radead.org>,
Vlastimil Babka <vbabka@...e.cz>
Cc: linux-mm@...ck.org, Roman Gushchin <guro@...com>,
Michal Hocko <mhocko@...nel.org>,
Johannes Weiner <hannes@...xchg.org>,
linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Mel Gorman <mgorman@...hsingularity.net>,
Vijayanand Jitta <vjitta@...eaurora.org>
Subject: Re: [RFC PATCH 0/5] kmalloc-reclaimable caches
On 05/24/2018 09:18 AM, Randy Dunlap wrote:
> On 05/24/2018 04:43 AM, Matthew Wilcox wrote:
>> On Thu, May 24, 2018 at 01:00:06PM +0200, Vlastimil Babka wrote:
>>> Now for the issues a.k.a. why RFC:
>>>
>>> - I haven't find any other obvious users for reclaimable kmalloc (yet)
>>
>> Is that a problem? This sounds like it's enough to solve Facebook's
>> problem.
>>
>>> - the name of caches kmalloc-reclaimable-X is rather long
>>
>> Yes; Christoph and I were talking about restricting slab names to 16 bytes
>> just to make /proc/slabinfo easier to read. How about
>>
>> kmalloc-rec-128k
>> 1234567890123456
>>
>> Just makes it ;-)
>>
>> Of course, somebody needs to do the work to use k/M instead of 4194304.
>> We also need to bikeshed about when to switch; should it be:
>>
>> kmalloc-rec-512
>> kmalloc-rec-1024
>> kmalloc-rec-2048
>> kmalloc-rec-4096
>> kmalloc-rec-8192
>> kmalloc-rec-16k
>>
>> or should it be
>>
>> kmalloc-rec-512
>> kmalloc-rec-1k
>> kmalloc-rec-2k
>> kmalloc-rec-4k
>> kmalloc-rec-8k
>> kmalloc-rec-16k
>>
>> I slightly favour the latter as it'll be easier to implement. Something like
>
> Yes, agree, start using the suffix early.
>
>>
>> static const char suffixes[3] = ' kM';
>> int idx = 0;
>>
>> while (size > 1024) {
I would use (size >= 1024)
so that 1M is printed instead of 1024K.
>> size /= 1024;
>> idx++;
>> }
>>
>> sprintf("%d%c", size, suffices[idx]);
>
> suffixes
>>
>> --
>
>
--
~Randy
Powered by blists - more mailing lists