On 2016-09-27 16:00, Florian Weimer wrote: > * Aurelien Jarno: > > > On 2016-09-27 13:44, Florian Weimer wrote: > >> * Aurelien Jarno: > >> > >> > Hmm, rsync doesn't use libpthread, so that clearly rules out a > >> > libpthread issue. That said, all the example you gave fail to allocate > >> > the memory correctly, either through malloc (glibc) or mmap (kernel) > >> > which returns -ENOMEM. This points to either a kernel issue, or a > >> > limitation of the memory using for example ulimit. > >> > >> The mm subsystem in the 4.7 upstream kernel has a very visible issue > >> which causes allocation failures: > >> > >> <http://marc.info/?l=linux-mm&m=147422898523307> > >> > >> There are other threads as well. (I personally see this with the > >> xfs_inode cache.) > >> > >> Usually it manifests in premature OOM killer invocations, but maybe > >> something the reporter's system configuration changes that (perhaps it > >> runs with vm.overcommit_memory=2?). > > > > Indeed, that is correct. The problem has been fixed in version 4.7.5, > > while the reporter seems to run version 4.7.4. Upgrading to the latest > > kernel version would be a good start. > > I don't think this has been fully fixed in 4.7.5. I'm running that > version now, and with lots of xfs_inode objects, I observe basically > zero read-ahead, which results in stuttering media playback with > ogg123. vm.drop_caches=3 makes the stuttgering go away. > > I need to see if I can still reproduce the OOMs. This was a bit > tricky before.
Ok. I have seen this change in 4.7.5: | commit bec4e55b55867ed948a3afd9f9ccf3506bfdad24 | Author: Michal Hocko <[email protected]> | Date: Thu Sep 1 16:14:41 2016 -0700 | | mm, oom: prevent premature OOM killer invocation for high order request So I assumed it fixes the issue. Maybe it only fixes it partially. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://www.aurel32.net
