linux-kernel - Re: [PATCH 13/28] shrinker: clean up variable types and tracepoints

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191104153049.GD10665@bfoster>
Date:   Mon, 4 Nov 2019 10:30:49 -0500
From:   Brian Foster <bfoster@...hat.com>
To:     Dave Chinner <david@...morbit.com>
Cc:     linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 13/28] shrinker: clean up variable types and tracepoints

On Fri, Nov 01, 2019 at 10:46:03AM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@...hat.com>
> 
> The tracepoint information in the shrinker code don't make a lot of

Nit:						  doesn't

> sense anymore and contain redundant information as a result of the
> changes in the patchset. Refine the information passed to the
> tracepoints so they expose the operation of the shrinkers more
> precisely and clean up the remaining code and varibles in the

Nit:						variables

> shrinker code so it all makes sense.
> 
> Signed-off-by: Dave Chinner <dchinner@...hat.com>
> ---
>  include/trace/events/vmscan.h | 69 ++++++++++++++++-------------------
>  mm/vmscan.c                   | 24 +++++-------
>  2 files changed, 41 insertions(+), 52 deletions(-)
> 
...
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index c0e2bf656e3f..7a8256322150 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
...
> @@ -624,23 +622,21 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl,
>  		cond_resched();
>  	}
>  done:
...
>  	if (next_deferred > 0)
> -		new_nr = atomic64_add_return(next_deferred,
> -						&shrinker->nr_deferred[nid]);
> -	else
> -		new_nr = atomic64_read(&shrinker->nr_deferred[nid]);
> +		atomic64_add(next_deferred, &shrinker->nr_deferred[nid]);
>  
> -	trace_mm_shrink_slab_end(shrinker, nid, freed, deferred_count, new_nr,
> -					scan_count);
> +	trace_mm_shrink_slab_end(shrinker, nid, freed, scanned_objects,
> +				 next_deferred);

I guess this invalidates my comment on the previous patch around new_nr.
Looks Ok to me:

Reviewed-by: Brian Foster <bfoster@...hat.com>

>  	return freed;
>  }
>  
> -- 
> 2.24.0.rc0
>