linux-kernel - Re: [PATCH 1/3] Add a new field to struct shrinker

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <15d2252f-8bb9-287b-0006-ef42bc8efd27@suse.de>
Date:	Thu, 11 Aug 2016 20:09:25 -0700
From:	Tony Jones <tonyj@...e.de>
To:	Mel Gorman <mgorman@...hsingularity.net>,
	Dave Chinner <david@...morbit.com>
Cc:	Janani Ravichandran <janani.rvchndrn@...il.com>,
	Rik van Riel <riel@...riel.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] Add a new field to struct shrinker

On 07/29/2016 06:00 AM, Mel Gorman wrote:
> On Fri, Jul 29, 2016 at 10:13:40AM +1000, Dave Chinner wrote:
>> On Thu, Jul 28, 2016 at 11:25:13AM +0100, Mel Gorman wrote:
>>> On Thu, Jul 28, 2016 at 03:49:47PM +1000, Dave Chinner wrote:
>>>> Seems you're all missing the obvious.
>>>>
>>>> Add a tracepoint for a shrinker callback that includes a "name"
>>>> field, have the shrinker callback fill it out appropriately. e.g
>>>> in the superblock shrinker:
>>>>
>>>> 	trace_shrinker_callback(shrinker, shrink_control, sb->s_type->name);
>>>>
>>>
>>> That misses capturing the latency of the call unless there is a begin/end
>>> tracepoint.
>>
>> Sure, but I didn't see that in the email talking about how to add a
>> name. Even if it is a requirement, it's not necessary as we've
>> already got shrinker runtime measurements from the
>> trace_mm_shrink_slab_start and trace_mm_shrink_slab_end trace
>> points. With the above callback event, shrinker call runtime is
>> simply the time between the calls to the same shrinker within
>> mm_shrink_slab start/end trace points.
>>
> 
> Fair point. It's not that hard to correlate them.

True but the scan_objects callback is only called if we have >batch_size objects.

It's possible to accumulate quite some time without calling the callback and being able to obtain 
the s_type->name.   So this time all gets associated with just super_cache_scan.