On Mon, Jul 11 2016 at 9:27am -0400, Matthias Dahl <ml_linux-kernel@xxxxxxxxxxxxxxxx> wrote: > Hello Mike... > > On 2016-07-11 15:18, Mike Snitzer wrote: > > >Something must explain the execessive nature of your leak but > >it isn't a known issue. > > Since I am currently setting up the new machine, all tests were > performed w/ various live cd images (Fedora Rawhide, Gentoo, ...) > and I saw the exact same behavior everywhere. > > >Have you tried running with kmemleak enabled? > > I would have to check if that is enabled on the live images but even if > it is, how would that work? The default interval is 10min. If I fire up > a dd, the memory is full within two seconds or so... and after that, the > OOM killer kicks in and all hell breaks loose unfortunately. You can control when kmemleak scans. See Documentation/kmemleak.txt You could manually trigger a scan just after the dd is started. But I doubt the livecds have kmemleak compiled into their kernels. > I don't think this is a particular unique issue on my side. You could, > if I am right, easily try a Fedora Rawhide image and reproduce it there > yourself. The only unique point here is my RAID10 which is a Intel Rapid > Storage s/w RAID. I have no clue if this could indeed cause such a "bug" > and how. What is your raid10's full stripesize? Is your dd IO size of 512K somehow triggering excess R-M-W cycles which is exacerbating the problem? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>