Intel graphics memory leak, and a possible solution
Posted: 25. Jul 2012, 20:06
With the current Slackware kernel (2.6.37.6), certain OpenGL programs will leak huge amounts of memory, quickly overrunning both RAM and swap. This doesn't happen with other kernels or other video chipsets, and can be reproduced quite reliably.
I banged my head against this for a while, and was considering a distro switch, until I stumbled across a simple and entirely unintuitive solution - booting with the 'noapic' kernel parameter. This eliminated the memory leakage entirely as far as I could tell.
I have no idea why this is; usually (in my experience) the need for noapic is signified by random freezes or kernel panics. If I had to guess, I'd say maybe there's something buggy in this kernel about the handling of interrupts from the video hardware; but really I'm talking off the top of my head here. Anyway, the point is it works for some reason; so if any of you have been having issues with 3D on this kernel and Intel chipsets, it's something you might want to try, even if your machine doesn't officially require noapic.
(NB: I'm not sure how big the performance impact of noapic is. Since IIRC it routes all IO interrupts to one core, I suspect the impact would increase quickly with the number of cores.)
I banged my head against this for a while, and was considering a distro switch, until I stumbled across a simple and entirely unintuitive solution - booting with the 'noapic' kernel parameter. This eliminated the memory leakage entirely as far as I could tell.
I have no idea why this is; usually (in my experience) the need for noapic is signified by random freezes or kernel panics. If I had to guess, I'd say maybe there's something buggy in this kernel about the handling of interrupts from the video hardware; but really I'm talking off the top of my head here. Anyway, the point is it works for some reason; so if any of you have been having issues with 3D on this kernel and Intel chipsets, it's something you might want to try, even if your machine doesn't officially require noapic.
(NB: I'm not sure how big the performance impact of noapic is. Since IIRC it routes all IO interrupts to one core, I suspect the impact would increase quickly with the number of cores.)