Re: OOM-killer going crazy.

Jens Axboe
2004-07-28T13:38:21Z

On Wed, Jul 28 2004, Ed Sweetman wrote:
> Jens Axboe wrote:
>
> >On Wed, Jul 28 2004, Ed Sweetman wrote:
> >
> >
> >>Nick Piggin wrote:
> >>
> >>
> >>
> >>>Ed Sweetman wrote:
> >>>
> >>>
> >>>
> >>>>Nick Piggin wrote:
> >>>>
> >>>>
> >>>>
> >>>>>OK so it does sound like a different problem.
> >>>>>
> >>>>>I didn't follow your other thread closely... does /proc/slabinfo
> >>>>>show any evidence of a leak?
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>Surprisingly no. You'd think that since the kernel is responsible for
> >>>>saying what memory can't be touched or swapped out it would have some
> >>>>sort of tag on the huge 600MB of ram I currently can't do anything
> >>>>with since i burned that audio cd but slabinfo doesn't seem to show
> >>>>anything about it. Maybe i'm reading it wrong.
> >>>>
> >>>>
> >>>>
> >>>It could be memory coming straight out of the page allocator that
> >>>isn't being freed.
> >>>
> >>>Jens, any ideas?
> >>>-
> >>>
> >>>
> >>
> >>Con Kolivas' 2.6.8-rc1-ck6 snapshot patch seems fix the problem. Not
> >>only is my audio not corrupted when i write a disk but I get no mem leak
> >>situation and thus no OOM. I did 5 dummy burns with no swap being used
> >>and stable vm statistics, final real burn resulted in successful disc.
> >>
> >>2.6.8-rc1 2.6.8-rc1-mm both flipped out. ck touches all relevent files
> >>so something the patch does fixed whatever was wrong.
> >>
> >>
> >
> >This makes about zero sense to me (a leak I can understand, corrupted
> >audio is more weird). Can you point me at the specific patch used?
> >
> >
> >
> the corruption may have been a combination of not burning a cd without
> -pad and without -swab at the same time as using -audio. It appears my
> drive burns audio just fine with just -audio as the argument for cdrecord.

The corruption issue _must_ be a user error.

> http://ck.kolivas.org/patches/2.6/2.6.7/2.6.8-rc1/snapshot-2.6.8-rc1-ck6-0407151120.bz2

Did you use cfq with the other kernels as well? If your problem isn't
one of the vm, I still don't see how this patch can make any difference
whatsoever. There are no changes to the paths used writing the data,
once you exit the page allocation.

--
Jens Axboe