On Mon, 5 May 2014, Dave Jones wrote:
> On Mon, May 05, 2014 at 08:08:02PM +0200, Thomas Gleixner wrote:
>
> > I twisted my brain around that for a fricking long time, but I really
> > can't see the failure in the code.
> >
> > Neither did I succeed to trigger the issue in a VM (with and without
> > function tracing) on Linus latest.
> >
> > I grabbed trinity source and did:
> >
> > # ./trinity -l off -c futex -q
> >
> > That should be enough, right?
>
> yeah, that should do it. That's with the version from git, or the
> last tarball ? (I really should do another tarball release)
git
> Maybe try with -c <some number bigger than processor count>.
> On my 4 way haswell, I run with -C40 just to keep things busy while some
> processes idle. For something like futex, which sleeps a lot, this might
> be important.
>
> > All I see in dmesg are occasional ooms which kill random trinity
> > childs.
>
> hm, that sounds odd. if it's only fuzzing futex, it shouldn't be
> doing much memory allocation.
It has a fast memory leak of some sort.
9271 tglx 20 0 198908 75320 2992 S 0.7 7.4 0:01.94 trinity-c0
9271 tglx 20 0 256888 104368 2992 S 3.3 10.2 0:02.78 trinity-c0
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
