[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130131211818.GA13195@gmail.com>
Date: Thu, 31 Jan 2013 22:18:18 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Yuanhan Liu <yuanhan.liu@...ux.intel.com>
Cc: Michel Lespinasse <walken@...gle.com>,
linux-kernel@...r.kernel.org, David Howells <dhowells@...hat.com>
Subject: Re: [PATCH] rwsem-spinlock: let rwsem write lock stealable
* Yuanhan Liu <yuanhan.liu@...ux.intel.com> wrote:
> On Thu, Jan 31, 2013 at 02:12:28PM +0100, Ingo Molnar wrote:
> >
> > * Yuanhan Liu <yuanhan.liu@...ux.intel.com> wrote:
> >
> > > BTW, mind to tell a nice test case for mmap_sem?
> >
> > this one was write-hitting on mmap_sem pretty hard, last I
> > checked:
> >
> > http://people.redhat.com/mingo/threaded-mmap-stresstest/
>
> Thanks!
>
> Is there any pass condition? I tested a while, at least I
> found no oops or any noisy from dmesg output. Is that OK?
Yeah, not crashing and not hanging is the expected behavior.
> Well, sometimes, it will quit peacefully. Sometimes it will
> not. ps -eo 'pid, state,wchan,comm' shows that it is sleeping
> at futex_wait_queue_me().
>
> NOTE: this happens both with or w/o this patch. Thus it may
> not an issue introduced by this patch?
hm, that's unexpected - it's expected to loop infinitely. I have
a newer version (attached) - is that exiting too?
Maybe this triggers spuriously:
if (!info->si_addr)
raise(SIGABRT); /* Allow GDB backtrace */
although then you should see the SIGABRT as an irregular exit
IIRC.
Thanks,
Ingo
Download attachment "threaded-mmap-stresstest.tar.gz" of type "application/x-gzip" (3036 bytes)
Powered by blists - more mailing lists