Re: OOM-killer going crazy.

[Nick Piggin <nickpiggin@yahoo.com.au>]

Ed Sweetman wrote:

> I tried it, i dont slow down or crash when burning the cd the first 
> time. It's a small cd that doesn't take up my entire ram size, but the 
> memory is still not freed. If i tried it again i would be rebooting 
> right now.  I only have 70MB out of 650MB free after burning the cd.  
> Cache only takes up 122MB, and buf takes up 1MB.  and i'm using 100MB of 
> swap. I will run vmstat when i do it when i get home later today.
> It's not so much that the kernel is leaking memory, I think it thinks 
> it's handling a pointer to data it's supposed to write to disk, but it's 
> writing the wrong data, either a slightly misaligned offset or mangled 
> pointer because the audio cd did write but the audio it wrote is 
> unintelligable.  It almost sort of sounds like it should but it's 
> completely fubared.  And i've done this with swab on and off before 
> thinking the drive automatically wrote audio with SWAB on and cdrecord's 
> swab was countering it or something but that was not the case.  The 
> audio source files were ripped from a cd using the same drive and they 
> sound good on the harddrive.  The drive seems to have no real problem 
> ripping audio. Just writing it.  Normal cds show no problem as i've 
> previously mentioned.
> If this is a vfs problem then i'd like to know what audio writing has to 
> do with filesystems since it's raw data.  Even ignoring the mem leak 
> problem that appears to manifest in different ways on different 
> computers, this OOM situation only happens to me when burning audio cds, 
> not data.
>

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?