Re: adding swap workarounds oom - was: Re: Out of Memory: Killed process 16498 (java).

[Jens Axboe <axboe@suse.de>]

On Fri, Feb 03 2006, Anton Altaparmakov wrote:
> Yes, I think it is suse.  I just diffed /mm of both the above kernels
> (.193 and .201) and I think there is a little typo which probably causes
> the problem.  It is mm/vmscan.c::shrink_zone():
> 
> @@ -845,19 +845,38 @@ shrink_zone(struct zone *zone, int max_s
>         }
> 
>         atomic_add(scan_active + 1, &zone->nr_scan_active);
> -       count = atomic_read(&zone->nr_scan_active);
> -       if (count >= SWAP_CLUSTER_MAX) {
> +       nr_active = atomic_read(&zone->nr_scan_active);
> +       if (nr_active >= SWAP_CLUSTER_MAX)
>                 atomic_set(&zone->nr_scan_active, 0);
> -               refill_inactive_zone(zone, count, ps, can_free_mapped);
> -       }
> +       else
> +               nr_active = 0;
> 
>         atomic_add(max_scan, &zone->nr_scan_inactive);
> -       count = atomic_read(&zone->nr_scan_inactive);
> -       if (count >= SWAP_CLUSTER_MAX) {
> +       nr_inactive = atomic_read(&zone->nr_scan_inactive);
> +       if (nr_active >= SWAP_CLUSTER_MAX)
>             ^^^^^^^^^ Should be nr_inactive I think.
> 
> Comparing to code in current linux-2.6.git/mm/vmscan.c confirms that it
> should be nr_inactive.
> 
>                 atomic_set(&zone->nr_scan_inactive, 0);
> -               return shrink_cache(zone, gfp_mask, count, total_scanned, can_free_mapped);
> +       else
> +               nr_inactive = 0;
> 
> Jens, given you have an @suse email address, do you want to kick whoever
> deals with this in novel/suse so it gets fixed in the next sles9 kernel
> update?

Auch, that looks nasty. I'll forward this, thanks!

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/