On Mon, 2013-08-12 at 20:52 +0200, Ingo Molnar wrote:
> * Tim Chen wrote:
>
> > On Tue, 2013-08-06 at 16:55 -0700, Davidlohr Bueso wrote:
> >
> > > I got good numbers, recovering the performance drop I noticed with the
> > > i_mmap_mutex to rwsem patches.
> >
> > That's good. I remembered that
* Tim Chen wrote:
> On Tue, 2013-08-06 at 16:55 -0700, Davidlohr Bueso wrote:
>
> > I got good numbers, recovering the performance drop I noticed with the
> > i_mmap_mutex to rwsem patches.
>
> That's good. I remembered that the earlier version of the patch not
> only recovered the performan
On Tue, 2013-08-06 at 16:55 -0700, Davidlohr Bueso wrote:
> I got good numbers, recovering the performance drop I noticed with the
> i_mmap_mutex to rwsem patches.
That's good. I remembered that the earlier version of the patch not
only recovered the performance drop, but also provide some boost
On Mon, 2013-07-29 at 17:13 -0700, Tim Chen wrote:
> On Tue, 2013-07-23 at 11:53 +0200, Ingo Molnar wrote:
> > * Peter Zijlstra wrote:
> >
> > > On Tue, Jul 23, 2013 at 11:45:13AM +0200, Ingo Molnar wrote:
> > >
> > > > Why not just try the delayed addition approach first? The spinning is
> > >
On Tue, 2013-07-30 at 21:24 +0200, Ingo Molnar wrote:
> >
> > Signed-off-by: Tim Chen
>
> > +config RWSEM_SPIN_ON_WRITE_OWNER
> > + bool "Optimistic spin write acquisition for writer owned rw-sem"
> > + default n
> > + depends on SMP
> > + help
> > + Allows a writer to perform optim
On Tue, 2013-07-30 at 13:34 -0700, Tim Chen wrote:
> On Tue, 2013-07-30 at 12:59 -0700, Davidlohr Bueso wrote:
> > cc'ing Dave Chinner for XFS
> >
>
> Davidlohr,
>
> I also wonder it this change benefit your workload. Will
> be interested to know of your performance numbers.
Yep, I'm currently
On Tue, 2013-07-30 at 12:59 -0700, Davidlohr Bueso wrote:
> cc'ing Dave Chinner for XFS
>
Davidlohr,
I also wonder it this change benefit your workload. Will
be interested to know of your performance numbers.
Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
cc'ing Dave Chinner for XFS
On Mon, 2013-07-29 at 17:13 -0700, Tim Chen wrote:
> On Tue, 2013-07-23 at 11:53 +0200, Ingo Molnar wrote:
> > * Peter Zijlstra wrote:
> >
> > > On Tue, Jul 23, 2013 at 11:45:13AM +0200, Ingo Molnar wrote:
> > >
> > > > Why not just try the delayed addition approach f
* Tim Chen wrote:
> On Tue, 2013-07-23 at 11:53 +0200, Ingo Molnar wrote:
> > * Peter Zijlstra wrote:
> >
> > > On Tue, Jul 23, 2013 at 11:45:13AM +0200, Ingo Molnar wrote:
> > >
> > > > Why not just try the delayed addition approach first? The spinning is
> > > > time limited AFAICS, so we d
On Tue, 2013-07-23 at 11:53 +0200, Ingo Molnar wrote:
> * Peter Zijlstra wrote:
>
> > On Tue, Jul 23, 2013 at 11:45:13AM +0200, Ingo Molnar wrote:
> >
> > > Why not just try the delayed addition approach first? The spinning is
> > > time limited AFAICS, so we don't _have to_ recognize those as w
* Peter Zijlstra wrote:
> On Tue, Jul 23, 2013 at 11:45:13AM +0200, Ingo Molnar wrote:
>
> > Why not just try the delayed addition approach first? The spinning is
> > time limited AFAICS, so we don't _have to_ recognize those as writers
> > per se, only if the spinning fails and it wants to go
On Tue, Jul 23, 2013 at 11:45:13AM +0200, Ingo Molnar wrote:
> Why not just try the delayed addition approach first? The spinning is time
> limited AFAICS, so we don't _have to_ recognize those as writers per se,
> only if the spinning fails and it wants to go on the waitlist. Am I
> missing som
* Tim Chen wrote:
> Ingo,
>
> I tried MCS locking to order the writers but it didn't make much
> difference on my particular workload. After thinking about this some
> more, a likely explanation of the performance difference between mutex
> and rwsem performance is:
>
> 1) Jobs acquiring mu
On Tue, 2013-07-02 at 08:45 +0200, Ingo Molnar wrote:
> * Tim Chen wrote:
>
> > On Sat, 2013-06-29 at 09:12 +0200, Ingo Molnar wrote:
> > > * Tim Chen wrote:
> > >
> > > > > If my analysis is correct so far then it might be useful to add two
> > > > > more stats: did rwsem_spin_on_owner() fail
* Tim Chen wrote:
> On Sat, 2013-06-29 at 09:12 +0200, Ingo Molnar wrote:
> > * Tim Chen wrote:
> >
> > > > If my analysis is correct so far then it might be useful to add two
> > > > more stats: did rwsem_spin_on_owner() fail because lock->owner == NULL
> > > > [owner released the rwsem], o
On Sat, 2013-06-29 at 09:12 +0200, Ingo Molnar wrote:
> * Tim Chen wrote:
>
> > > If my analysis is correct so far then it might be useful to add two
> > > more stats: did rwsem_spin_on_owner() fail because lock->owner == NULL
> > > [owner released the rwsem], or because owner_running() failed
* Tim Chen wrote:
> > If my analysis is correct so far then it might be useful to add two
> > more stats: did rwsem_spin_on_owner() fail because lock->owner == NULL
> > [owner released the rwsem], or because owner_running() failed [owner
> > went to sleep]?
>
> Ingo,
>
> I tabulated the cas
On Fri, 2013-06-28 at 11:38 +0200, Ingo Molnar wrote:
> * Tim Chen wrote:
>
> > I tried some tweaking that checks sem->count for read owned lock. Even
> > though it reduces the percentage of acquisitions that need sleeping by
> > 8.14% (from 18.6% to 10.46%), it increases the writer acquisition
* Tim Chen wrote:
> I tried some tweaking that checks sem->count for read owned lock. Even
> though it reduces the percentage of acquisitions that need sleeping by
> 8.14% (from 18.6% to 10.46%), it increases the writer acquisition
> blocked count by 11%. This change still doesn't boost throu
* Tim Chen wrote:
> > Yet the 17.6% sleep percentage is still much higher than the 1% in the
> > mutex case. Why doesn't spinning work - do we time out of spinning
> > differently?
>
> I have some stats for the 18.6% cases (including 1% more than 1 sleep
> cases) that go to sleep and failed
On Thu, 2013-06-27 at 13:53 -0700, Tim Chen wrote:
> On Thu, 2013-06-27 at 10:36 +0200, Ingo Molnar wrote:
> > * Tim Chen wrote:
> >
> > > On Wed, 2013-06-26 at 14:36 -0700, Tim Chen wrote:
> > > > On Wed, 2013-06-26 at 11:51 +0200, Ingo Molnar wrote:
> > > > > * Tim Chen wrote:
> > > > >
> >
On Thu, 2013-06-27 at 10:36 +0200, Ingo Molnar wrote:
> * Tim Chen wrote:
>
> > On Wed, 2013-06-26 at 14:36 -0700, Tim Chen wrote:
> > > On Wed, 2013-06-26 at 11:51 +0200, Ingo Molnar wrote:
> > > > * Tim Chen wrote:
> > > >
> > > > > On Wed, 2013-06-19 at 09:53 -0700, Tim Chen wrote:
> > > >
* Tim Chen wrote:
> On Wed, 2013-06-26 at 14:36 -0700, Tim Chen wrote:
> > On Wed, 2013-06-26 at 11:51 +0200, Ingo Molnar wrote:
> > > * Tim Chen wrote:
> > >
> > > > On Wed, 2013-06-19 at 09:53 -0700, Tim Chen wrote:
> > > > > On Wed, 2013-06-19 at 15:16 +0200, Ingo Molnar wrote:
> > > > >
On Wed, 2013-06-26 at 14:36 -0700, Tim Chen wrote:
> On Wed, 2013-06-26 at 11:51 +0200, Ingo Molnar wrote:
> > * Tim Chen wrote:
> >
> > > On Wed, 2013-06-19 at 09:53 -0700, Tim Chen wrote:
> > > > On Wed, 2013-06-19 at 15:16 +0200, Ingo Molnar wrote:
> > > >
> > > > > > vmstat for mutex imple
On Wed, 2013-06-26 at 11:51 +0200, Ingo Molnar wrote:
> * Tim Chen wrote:
>
> > On Wed, 2013-06-19 at 09:53 -0700, Tim Chen wrote:
> > > On Wed, 2013-06-19 at 15:16 +0200, Ingo Molnar wrote:
> > >
> > > > > vmstat for mutex implementation:
> > > > > procs ---memory-- ---swap--
* Tim Chen wrote:
> On Wed, 2013-06-19 at 09:53 -0700, Tim Chen wrote:
> > On Wed, 2013-06-19 at 15:16 +0200, Ingo Molnar wrote:
> >
> > > > vmstat for mutex implementation:
> > > > procs ---memory-- ---swap-- -io --system--
> > > > -cpu-
> > > > r b swpd
On Wed, 2013-06-19 at 09:53 -0700, Tim Chen wrote:
> On Wed, 2013-06-19 at 15:16 +0200, Ingo Molnar wrote:
>
> > > vmstat for mutex implementation:
> > > procs ---memory-- ---swap-- -io --system--
> > > -cpu-
> > > r b swpd free buff cache si sob
On Wed, 2013-06-19 at 16:11 -0700, Davidlohr Bueso wrote:
> On Mon, 2013-06-17 at 17:08 -0700, Tim Chen wrote:
> > On Mon, 2013-06-17 at 16:35 -0700, Davidlohr Bueso wrote:
> > > On Tue, 2013-06-18 at 07:20 +0800, Alex Shi wrote:
> > > > On 06/18/2013 12:22 AM, Davidlohr Bueso wrote:
> > > > > Afte
On Mon, 2013-06-17 at 17:08 -0700, Tim Chen wrote:
> On Mon, 2013-06-17 at 16:35 -0700, Davidlohr Bueso wrote:
> > On Tue, 2013-06-18 at 07:20 +0800, Alex Shi wrote:
> > > On 06/18/2013 12:22 AM, Davidlohr Bueso wrote:
> > > > After a lot of benchmarking, I finally got the ideal results for aim7,
>
On Wed, 2013-06-19 at 15:16 +0200, Ingo Molnar wrote:
> > vmstat for mutex implementation:
> > procs ---memory-- ---swap-- -io --system--
> > -cpu-
> > r b swpd free buff cache si sobibo in cs us sy id
> > wa st
> > 38 0 0 130957920
* Tim Chen wrote:
> Ingo,
>
> At the time of switching the anon-vma tree's lock from mutex to
> rw-sem (commit 5a505085), we encountered regressions for fork heavy workload.
> A lot of optimizations to rw-sem (e.g. lock stealing) helped to
> mitigate the problem. I tried an experiment on th
On Mon, 2013-06-17 at 16:35 -0700, Davidlohr Bueso wrote:
> On Tue, 2013-06-18 at 07:20 +0800, Alex Shi wrote:
> > On 06/18/2013 12:22 AM, Davidlohr Bueso wrote:
> > > After a lot of benchmarking, I finally got the ideal results for aim7,
> > > so far: this patch + optimistic spinning with preempti
On Tue, 2013-06-18 at 07:20 +0800, Alex Shi wrote:
> On 06/18/2013 12:22 AM, Davidlohr Bueso wrote:
> > After a lot of benchmarking, I finally got the ideal results for aim7,
> > so far: this patch + optimistic spinning with preemption disabled. Just
> > like optimistic spinning, this patch by itse
On 06/18/2013 12:22 AM, Davidlohr Bueso wrote:
> After a lot of benchmarking, I finally got the ideal results for aim7,
> so far: this patch + optimistic spinning with preemption disabled. Just
> like optimistic spinning, this patch by itself makes little to no
> difference, yet combined is where w
On 06/18/2013 02:45 AM, Tim Chen wrote:
>>> + if (unlikely(sem->count < RWSEM_WAITING_BIAS)) {
>>> > > + cpu_relax();
>>> > > + continue;
>>> > > + }
> The above two if statements could be cleaned up
On Mon, 2013-06-17 at 12:05 -0700, Davidlohr Bueso wrote:
> >
> > Thanks. Those are encouraging numbers. On my exim workload I didn't
> > get a boost when I added in the preempt disable in optimistic spin and
> > put Alex's changes in. Can you send me your combined patch to see if
> > there may
On Fri, 2013-06-14 at 15:47 -0700, Michel Lespinasse wrote:
> On Fri, Jun 14, 2013 at 3:31 PM, Davidlohr Bueso
> wrote:
> > A few ideas that come to mind are avoiding taking the ->wait_lock and
> > avoid dealing with waiters when doing the optimistic spinning (just like
> > mutexes do).
> >
> > I
On Mon, 2013-06-17 at 11:45 -0700, Tim Chen wrote:
> On Mon, 2013-06-17 at 09:22 -0700, Davidlohr Bueso wrote:
> > On Sun, 2013-06-16 at 17:50 +0800, Alex Shi wrote:
> > > On 06/14/2013 07:43 AM, Davidlohr Bueso wrote:
> > > > I was hoping that the lack of spin on owner was the main difference with
On Mon, 2013-06-17 at 09:22 -0700, Davidlohr Bueso wrote:
> On Sun, 2013-06-16 at 17:50 +0800, Alex Shi wrote:
> > On 06/14/2013 07:43 AM, Davidlohr Bueso wrote:
> > > I was hoping that the lack of spin on owner was the main difference with
> > > rwsems and am/was in the middle of implementing it.
On Sun, 2013-06-16 at 17:50 +0800, Alex Shi wrote:
> On 06/14/2013 07:43 AM, Davidlohr Bueso wrote:
> > I was hoping that the lack of spin on owner was the main difference with
> > rwsems and am/was in the middle of implementing it. Could you send your
> > patch so I can give it a try on my workloa
On 06/14/2013 07:43 AM, Davidlohr Bueso wrote:
> I was hoping that the lack of spin on owner was the main difference with
> rwsems and am/was in the middle of implementing it. Could you send your
> patch so I can give it a try on my workloads?
>
> Note that there have been a few recent (3.10) chan
On Fri, Jun 14, 2013 at 3:31 PM, Davidlohr Bueso wrote:
> A few ideas that come to mind are avoiding taking the ->wait_lock and
> avoid dealing with waiters when doing the optimistic spinning (just like
> mutexes do).
>
> I agree that we should first deal with the optimistic spinning before
> addi
>
> Unfortunately this patch didn't make any difference, in fact it hurt
> several of the workloads even more. I also tried disabling preemption
> when spinning on owner to actually resemble spinlocks, which was my
> original plan, yet not much difference.
>
That's also similar to the performa
On Fri, 2013-06-14 at 09:09 -0700, Tim Chen wrote:
> Added copy to mailing list which I forgot in my previous reply:
>
> On Thu, 2013-06-13 at 16:43 -0700, Davidlohr Bueso wrote:
> > On Thu, 2013-06-13 at 16:15 -0700, Tim Chen wrote:
> > > Ingo,
> > >
> > > At the time of switching the anon-vma t
Added copy to mailing list which I forgot in my previous reply:
On Thu, 2013-06-13 at 16:43 -0700, Davidlohr Bueso wrote:
> On Thu, 2013-06-13 at 16:15 -0700, Tim Chen wrote:
> > Ingo,
> >
> > At the time of switching the anon-vma tree's lock from mutex to
> > rw-sem (commit 5a505085), we encoun
45 matches
Mail list logo
