On Thu, Jan 31, 2013 at 10:18:18PM +0100, Ingo Molnar wrote:
>
> * Yuanhan Liu wrote:
>
> > On Thu, Jan 31, 2013 at 02:12:28PM +0100, Ingo Molnar wrote:
> > >
> > > * Yuanhan Liu wrote:
> > >
> > > > BTW, mind to tell a nice test case for mmap_sem?
> > >
> > > this one was write-hitting on
* Yuanhan Liu wrote:
> On Thu, Jan 31, 2013 at 02:12:28PM +0100, Ingo Molnar wrote:
> >
> > * Yuanhan Liu 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:
> >
> >
On Thu, Jan 31, 2013 at 02:12:28PM +0100, Ingo Molnar wrote:
>
> * Yuanhan Liu 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
* Yuanhan Liu 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,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe
* Michel Lespinasse wrote:
> On Wed, Jan 30, 2013 at 1:14 AM, Yuanhan Liu
> wrote:
> > We(Linux Kernel Performance project) found a regression introduced by
> > commit 5a50508, which just convert all mutex lock to rwsem write lock.
> > The semantics is same, but the results is quite huge in
On Thu, Jan 31, 2013 at 03:57:51AM -0800, Michel Lespinasse wrote:
> On Wed, Jan 30, 2013 at 1:14 AM, Yuanhan Liu
> wrote:
> > We(Linux Kernel Performance project) found a regression introduced by
> > commit 5a50508, which just convert all mutex lock to rwsem write lock.
> > The semantics is
On Thu, Jan 31, 2013 at 11:45:41AM +0100, Ingo Molnar wrote:
>
> * Yuanhan Liu wrote:
>
> > > > output with this patch:
> > > > ---
> > > > cpu 00: 0 0 ... 1 1 2 1 1 1 2 1 1 1 1 3
> > > > cpu 01: 0 0 ... 1 1 1 1 1 1 2 1
On Wed, Jan 30, 2013 at 1:14 AM, Yuanhan Liu
wrote:
> We(Linux Kernel Performance project) found a regression introduced by
> commit 5a50508, which just convert all mutex lock to rwsem write lock.
> The semantics is same, but the results is quite huge in some cases.
> After investigation, we
* Yuanhan Liu wrote:
> > > output with this patch:
> > > ---
> > > cpu 00: 0 0 ... 1 1 2 1 1 1 2 1 1 1 1 3
> > > cpu 01: 0 0 ... 1 1 1 1 1 1 2 1 1 1 1 3
> > > cpu 02: 0 0 ... 2 2 3 2 0 2 1
On Thu, Jan 31, 2013 at 10:39:31AM +0100, Ingo Molnar wrote:
>
> * Yuanhan Liu wrote:
>
> > We(Linux Kernel Performance project) found a regression introduced by
> > commit 5a50508, which just convert all mutex lock to rwsem write lock.
> > The semantics is same, but the results is quite huge
* Yuanhan Liu wrote:
> We(Linux Kernel Performance project) found a regression introduced by
> commit 5a50508, which just convert all mutex lock to rwsem write lock.
> The semantics is same, but the results is quite huge in some cases.
> After investigation, we found the root cause: mutex
* Yuanhan Liu yuanhan@linux.intel.com wrote:
We(Linux Kernel Performance project) found a regression introduced by
commit 5a50508, which just convert all mutex lock to rwsem write lock.
The semantics is same, but the results is quite huge in some cases.
After investigation, we found the
On Thu, Jan 31, 2013 at 10:39:31AM +0100, Ingo Molnar wrote:
* Yuanhan Liu yuanhan@linux.intel.com wrote:
We(Linux Kernel Performance project) found a regression introduced by
commit 5a50508, which just convert all mutex lock to rwsem write lock.
The semantics is same, but the
* Yuanhan Liu yuanhan@linux.intel.com wrote:
output with this patch:
---
cpu 00: 0 0 ... 1 1 2 1 1 1 2 1 1 1 1 3
cpu 01: 0 0 ... 1 1 1 1 1 1 2 1 1 1 1 3
cpu 02: 0 0 ... 2 2 3 2
On Wed, Jan 30, 2013 at 1:14 AM, Yuanhan Liu
yuanhan@linux.intel.com wrote:
We(Linux Kernel Performance project) found a regression introduced by
commit 5a50508, which just convert all mutex lock to rwsem write lock.
The semantics is same, but the results is quite huge in some cases.
After
On Thu, Jan 31, 2013 at 11:45:41AM +0100, Ingo Molnar wrote:
* Yuanhan Liu yuanhan@linux.intel.com wrote:
output with this patch:
---
cpu 00: 0 0 ... 1 1 2 1 1 1 2 1 1 1 1 3
cpu 01: 0 0 ... 1 1 1 1 1 1
On Thu, Jan 31, 2013 at 03:57:51AM -0800, Michel Lespinasse wrote:
On Wed, Jan 30, 2013 at 1:14 AM, Yuanhan Liu
yuanhan@linux.intel.com wrote:
We(Linux Kernel Performance project) found a regression introduced by
commit 5a50508, which just convert all mutex lock to rwsem write lock.
* Michel Lespinasse wal...@google.com wrote:
On Wed, Jan 30, 2013 at 1:14 AM, Yuanhan Liu
yuanhan@linux.intel.com wrote:
We(Linux Kernel Performance project) found a regression introduced by
commit 5a50508, which just convert all mutex lock to rwsem write lock.
The semantics is same,
* Yuanhan Liu yuanhan@linux.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,
Ingo
--
To unsubscribe from this list: send the
On Thu, Jan 31, 2013 at 02:12:28PM +0100, Ingo Molnar wrote:
* Yuanhan Liu yuanhan@linux.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:
* Yuanhan Liu yuanhan@linux.intel.com wrote:
On Thu, Jan 31, 2013 at 02:12:28PM +0100, Ingo Molnar wrote:
* Yuanhan Liu yuanhan@linux.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:
On Thu, Jan 31, 2013 at 10:18:18PM +0100, Ingo Molnar wrote:
* Yuanhan Liu yuanhan@linux.intel.com wrote:
On Thu, Jan 31, 2013 at 02:12:28PM +0100, Ingo Molnar wrote:
* Yuanhan Liu yuanhan@linux.intel.com wrote:
BTW, mind to tell a nice test case for mmap_sem?
We(Linux Kernel Performance project) found a regression introduced by
commit 5a50508, which just convert all mutex lock to rwsem write lock.
The semantics is same, but the results is quite huge in some cases.
After investigation, we found the root cause: mutex support lock
stealing. Here is the
We(Linux Kernel Performance project) found a regression introduced by
commit 5a50508, which just convert all mutex lock to rwsem write lock.
The semantics is same, but the results is quite huge in some cases.
After investigation, we found the root cause: mutex support lock
stealing. Here is the
24 matches
Mail list logo