mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Richard Kennedy <richard@rsk.demon.co.uk>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: den@openvz.org, lkml <linux-kernel@vger.kernel.org>,
	Michael Rubin <mrubin@google.com>
Subject: Re: Possible fix for lockup in drop_caches
Date: Mon, 24 Dec 2007 12:58:43 +0000	[thread overview]
Message-ID: <1198501123.2914.13.camel@castor.localdomain> (raw)
In-Reply-To: <20071222020611.9e4e78dd.akpm@linux-foundation.org>


On Sat, 2007-12-22 at 02:06 -0800, Andrew Morton wrote:
> On Mon, 17 Dec 2007 12:13:22 +0000 richard <richard@rsk.demon.co.uk> wrote:
> 
> >     fix lockup in when calling drop_caches
> >     
> >     calling /proc/sys/vm/drop_caches can hang due to a AB/BA lock dependency
> >     between j_list_lock and the inode_lock. This patch moves the redirtying of the buffer head out
> >     from under the j_list_lock.
> >     
> >     based on a suggestion by Andrew Morton.
> >     
> 
> Oh boy.  Do we really want to add all this stuff to JBD just for
> drop_caches which is a silly root-only broken-in-22-other-ways thing?

It did end up with a lot of code but I was hoping that not taking 2
locks at the same time would have a positive performance benefit, not
just fix the lockup. But, so far I've not been able to find a benchmark
to show any consistent difference.

However, I'm getting some interesting numbers from iozone that suggest
this patch improves write performance when the buffers are small enough
to fit into memory, _but_ the results are very variable. I'm not sure
why the iozone results are so inconsistent, maybe oprofile will help.
Anyway more testing is needed :)   

> Michael, might your convert-inode-lists-to-tree patches eliminate the need
> for taking inode_lock in drop_pagecache_sb()?  Probably not, as it uses an
> rbtree.  It would have been possible if it was using a radix-tree, I
> suspect..
> 
> > -void __journal_unfile_buffer(struct journal_head *jh)
> > +void __journal_unfile_buffer(struct journal_head *jh,
> > +		struct buffer_head **dirty_bh)
> >  {
> > -	__journal_temp_unlink_buffer(jh);
> > +	__journal_temp_unlink_buffer(jh, dirty_bh);
> >  	jh->b_transaction = NULL;
> >  }
> 
> I suspect the code would end up simpler if __journal_unfile_buffer() were
> to take an additional ref on the bh which it placed at *dirty_bh.
> 
> Callers of __journal_unfile_buffer() could then call
> 
> void handle_dirty_bh(struct buffer_head *bh)
> {
> 	if (bh) {
> 		jbd_mark_buffer_dirty(bh);
> 		put_bh(bh);
> 	}
> }

thanks for the suggestion, that looks like a really clean approach, I'll
give it a try.

cheers
Richard 



  reply	other threads:[~2007-12-24 14:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-17 12:13 richard
2007-12-22 10:06 ` Andrew Morton
2007-12-24 12:58   ` Richard Kennedy [this message]
2008-01-08 21:17   ` Michael Rubin
2008-01-08 21:19   ` Michael Rubin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1198501123.2914.13.camel@castor.localdomain \
    --to=richard@rsk.demon.co.uk \
    --cc=akpm@linux-foundation.org \
    --cc=den@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrubin@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®