Prev: perf pmu interface changes -v3
Next: [PATCH] edd: fix possible memory leak in edd_init() error path
From: Minchan Kim on 9 Jul 2010 07:00
On Fri, Jul 9, 2010 at 7:13 PM, KOSAKI Motohiro
<kosaki.motohiro(a)jp.fujitsu.com> wrote:
> If number of reclaimable slabs are zero, shrink_icache_memory() and
> shrink_dcache_memory() return 0. but strangely shrink_slab() ignore
> it and continue meaningless loop iteration.
>
> This patch fixes it.
>
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com>
> ---
> �mm/vmscan.c | � �5 +++++
> �1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 0f9f624..8f61adb 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -243,6 +243,11 @@ unsigned long shrink_slab(unsigned long scanned, gfp_t gfp_mask,
> � � � � � � � � � � � �int nr_before;
>
> � � � � � � � � � � � �nr_before = (*shrinker->shrink)(0, gfp_mask);
> + � � � � � � � � � � � /* no slab objects, no more reclaim. */
> + � � � � � � � � � � � if (nr_before == 0) {
> + � � � � � � � � � � � � � � � total_scan = 0;

Why do you reset totoal_scan to 0?
I don't know exact meaning of shrinker->nr.
AFAIU, it can affect next shrinker's total_scan.
Isn't it harmful?

--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: perf pmu interface changes -v3
Next: [PATCH] edd: fix possible memory leak in edd_init() error path