[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1405081726250.6261@ionos.tec.linutronix.de>
Date: Thu, 8 May 2014 17:28:54 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Dave Jones <davej@...hat.com>
cc: Linux Kernel <linux-kernel@...r.kernel.org>, peterz@...radead.org,
davidlohr@...com, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [3.15-rc3] rtmutex-debug assertion.
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists