Re: OOM-killer going crazy.

[Jens Axboe]

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

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