On 07/20, Jan Kara wrote:
>
> On Sat 18-07-15 08:40:15, Dave Chinner wrote:
> >
> > So, yes, it may well be a stale comment now.
>
> Yeah, as far as I remember this was the reason why I added the comment. So
> Oleg, feel free to remove the special code and run xfstests with XFS and
> lockdep enable
On Sat 18-07-15 08:40:15, Dave Chinner wrote:
> On Fri, Jul 17, 2015 at 07:31:17PM +0200, Oleg Nesterov wrote:
> > On 07/17, Dave Chinner wrote:
> > >
> > > On Thu, Jul 16, 2015 at 07:32:56PM +0200, Oleg Nesterov wrote:
> > > >
> > > > #ifdef CONFIG_LOCKDEP
> > > > /*
> > >
On 07/18, Dave Chinner wrote:
>
> On Fri, Jul 17, 2015 at 07:31:17PM +0200, Oleg Nesterov wrote:
> >
> > Dave, I didn't write this comment. Please look at acquire_freeze_lock().
> > If we can remove this logic - great! but this needs a separate change.
>
> Oh, I think I know what it was - when we d
On Fri, Jul 17, 2015 at 07:31:17PM +0200, Oleg Nesterov wrote:
> On 07/17, Dave Chinner wrote:
> >
> > On Thu, Jul 16, 2015 at 07:32:56PM +0200, Oleg Nesterov wrote:
> > >
> > > #ifdef CONFIG_LOCKDEP
> > > /*
> > >* We want lockdep to tell us about possible deadlocks with
>
On 07/17, Dave Chinner wrote:
>
> On Thu, Jul 16, 2015 at 07:32:56PM +0200, Oleg Nesterov wrote:
> >
> > #ifdef CONFIG_LOCKDEP
> > /*
> > * We want lockdep to tell us about possible deadlocks with
> > freezing but
> > * it's it bit tricky to properly instr
On Thu, Jul 16, 2015 at 07:32:56PM +0200, Oleg Nesterov wrote:
>
> #ifdef CONFIG_LOCKDEP
> /*
>* We want lockdep to tell us about possible deadlocks with
> freezing but
>* it's it bit tricky to properly instrument it. Getting a
> freeze protect
On 07/16, Jan Kara wrote:
>
> On Wed 15-07-15 20:19:20, Oleg Nesterov wrote:
> >
> > Perhaps it makes to merge other 2 patches from Dave first? (those which
> > change __sb_start/end_write to rely on RCU). Afaics these changes are
> > straightforward and correct. Although I'd suggest to use preempt
On Thu 16-07-15 00:30:27, Dave Hansen wrote:
> On 07/16/2015 12:26 AM, Jan Kara wrote:
> > So Dave's patches would go in only in the next merge window anyway so we
> > still have like two-three weeks to decide which patchset to take. If you
> > think it will take you longer, then merging Dave's pat
On 07/16/2015 12:26 AM, Jan Kara wrote:
> So Dave's patches would go in only in the next merge window anyway so we
> still have like two-three weeks to decide which patchset to take. If you
> think it will take you longer, then merging Dave's patches makes some sense
> although I personally don't t
On Wed 15-07-15 20:19:20, Oleg Nesterov wrote:
> On 07/15, Jan Kara wrote:
> > So I'm also in favor of Oleg's approach
> > as well. We just have to wait until he fixes the outstanding issues with
> > his code.
>
> Yes. I'll try to make the working version, hopefully this week.
>
> But,
>
> > Dav
On 07/15, Jan Kara wrote:
>
> On Tue 14-07-15 14:41:13, Dave Hansen wrote:
> >
> > I looked at it again. I tested with this patch in addition to the ones
> > modifying __sb_start/end_write():
> >
> > https://lkml.org/lkml/2015/6/24/682
> >
> > That is where the performance delta came from. Yo
On Tue 14-07-15 14:41:13, Dave Hansen wrote:
> On 07/14/2015 02:22 PM, Oleg Nesterov wrote:
> >> Using my little write-1-byte test (under will-it-scale), your 4 patches
> >> improves the number of writes/sec by 12%. My 3 patches improve the
> >> number of writes/sec by 32%.
>
> I looked at it aga
On 07/14/2015 02:22 PM, Oleg Nesterov wrote:
>> Using my little write-1-byte test (under will-it-scale), your 4 patches
>> improves the number of writes/sec by 12%. My 3 patches improve the
>> number of writes/sec by 32%.
I looked at it again. I tested with this patch in addition to the ones
mod
On 07/14, Dave Hansen wrote:
>
> On 07/14/2015 06:37 AM, Oleg Nesterov wrote:
> > On 07/14, Jan Kara wrote:
> >> So unless
> >> I'm missing something and there is a significant performance advantage to
> >> Dave's patches I'm all for using a generic primitive you suggest.
> >
> > I think percpu_rw_
On 07/14/2015 06:37 AM, Oleg Nesterov wrote:
> On 07/14, Jan Kara wrote:
>> So unless
>> I'm missing something and there is a significant performance advantage to
>> Dave's patches I'm all for using a generic primitive you suggest.
>
> I think percpu_rw_semaphore looks a bit better. And even a bit
On 07/14, Jan Kara wrote:
>
> Hello,
>
> On Mon 13-07-15 23:25:36, Oleg Nesterov wrote:
> > Al, Jan, could you comment? I mean the intent, the patches are
> > obviously not for inclusion yet.
>
> Thanks for the patches! Hum, what do people have with freeze protection
> these days? Noone cared abo
Hello,
On Mon 13-07-15 23:25:36, Oleg Nesterov wrote:
> Al, Jan, could you comment? I mean the intent, the patches are
> obviously not for inclusion yet.
Thanks for the patches! Hum, what do people have with freeze protection
these days? Noone cared about it for years and sudddently two patch s
On Tue, Jul 14, 2015 at 12:42:37AM +0200, Oleg Nesterov wrote:
> On 07/14, Dave Chinner wrote:
> >
> > [ Please cc linux-fsde...@vger.kernel.org on filesystem
> > infrastructure changes! ]
>
> OK, will do.
>
> > On Mon, Jul 13, 2015 at 11:25:36PM +0200, Oleg Nesterov wrote:
> > >
> > > - sb_loc
On 07/14, Dave Chinner wrote:
>
> [ Please cc linux-fsde...@vger.kernel.org on filesystem
> infrastructure changes! ]
OK, will do.
> On Mon, Jul 13, 2015 at 11:25:36PM +0200, Oleg Nesterov wrote:
> >
> > - sb_lockdep_release() and sb_lockdep_acquire() play with
> > percpu_rw_semaphore's
[ Please cc linux-fsde...@vger.kernel.org on filesystem
infrastructure changes! ]
On Mon, Jul 13, 2015 at 11:25:36PM +0200, Oleg Nesterov wrote:
> Hello,
>
> Al, Jan, could you comment? I mean the intent, the patches are
> obviously not for inclusion yet.
>
> We can remove everything from struct
20 matches
Mail list logo
