Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.
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 <mhocko@suse.com>
| 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
aurelien@aurel32.net http://www.aurel32.net
Reply to: