All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 3/5] repair: phase 6 is trivially parallelisable
Date: Fri, 13 Dec 2013 07:53:12 +1100	[thread overview]
Message-ID: <20131212205311.GZ10988@dastard> (raw)
In-Reply-To: <20131212184346.GA23479@infradead.org>

On Thu, Dec 12, 2013 at 10:43:46AM -0800, Christoph Hellwig wrote:
> >  static void
> >  add_dotdot_update(
> > @@ -64,12 +65,14 @@ add_dotdot_update(
> >  		do_error(_("malloc failed add_dotdot_update (%zu bytes)\n"),
> >  			sizeof(dotdot_update_t));
> >  
> > +	pthread_mutex_lock(&dotdot_lock);
> >  	dir->next = dotdot_update_list;
> >  	dir->irec = irec;
> >  	dir->agno = agno;
> >  	dir->ino_offset = ino_offset;
> >  
> >  	dotdot_update_list = dir;
> > +	pthread_mutex_unlock(&dotdot_lock);
> 
> Would be nice to make this use a list_head if you touch it anyway.
> (As a separate patch)
> 
> >  static void
> >  traverse_ags(
> > -	xfs_mount_t 		*mp)
> > +	xfs_mount_t		*mp)
> 
> Not quite sure what actually changed here, but if you touch it anyway
> you might as well use the struct version..

Whitespace after xfs_mount_t, judging by the highlighting I see in
the editor right now.

> > +	if (!ag_stride) {
> > +		work_queue_t	queue;
> > +
> > +		queue.mp = mp;
> > +		pf_args[0] = start_inode_prefetch(0, 1, NULL);
> > +		for (i = 0; i < glob_agcount; i++) {
> > +			pf_args[(~i) & 1] = start_inode_prefetch(i + 1, 1,
> > +					pf_args[i & 1]);
> > +			traverse_function(&queue, i, pf_args[i & 1]);
> > +		}
> > +		return;
> >  	}
> > +
> > +	/*
> > +	 * create one worker thread for each segment of the volume
> > +	 */
> > +	queues = malloc(thread_count * sizeof(work_queue_t));
> > +	for (i = 0, agno = 0; i < thread_count; i++) {
> > +		create_work_queue(&queues[i], mp, 1);
> > +		pf_args[0] = NULL;
> > +		for (j = 0; j < ag_stride && agno < glob_agcount; j++, agno++) {
> > +			pf_args[0] = start_inode_prefetch(agno, 1, pf_args[0]);
> > +			queue_work(&queues[i], traverse_function, agno,
> > +				   pf_args[0]);
> > +		}
> > +	}
> > +
> > +	/*
> > +	 * wait for workers to complete
> > +	 */
> > +	for (i = 0; i < thread_count; i++)
> > +		destroy_work_queue(&queues[i]);
> > +	free(queues);
> 
> 
> This is the third copy of this code block, might make sense to
> consolidate it.

Agreed, just haven't got to it.

> Btw, does anyone remember why we have the libxfs_bcache_overflowed()
> special case in phase4, but not anywhere else?

I recall something about memory consumption, but I doubt that code
can even trigger given that if we get to overflow conditions we
immediately double the cache size and so libxfs_bcache_overflowed()
will never see an overflow condition....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-12-12 20:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-12  7:22 [PATCH 0/5] xfs_repair: scalability inmprovements Dave Chinner
2013-12-12  7:22 ` [PATCH 1/5] repair: translation lookups limit scalability Dave Chinner
2013-12-12 18:26   ` Christoph Hellwig
2013-12-12 18:58   ` Brian Foster
2013-12-12  7:22 ` [PATCH 2/5] repair: per AG locks contend for cachelines Dave Chinner
2013-12-12 18:27   ` Christoph Hellwig
2013-12-12 18:58   ` Brian Foster
2013-12-12 20:46     ` Dave Chinner
2013-12-12  7:22 ` [PATCH 3/5] repair: phase 6 is trivially parallelisable Dave Chinner
2013-12-12 18:43   ` Christoph Hellwig
2013-12-12 20:53     ` Dave Chinner [this message]
2013-12-12 18:59   ` Brian Foster
2013-12-12  7:22 ` [PATCH 4/5] libxfs: buffer cache hashing is suboptimal Dave Chinner
2013-12-12 18:28   ` Christoph Hellwig
2013-12-12 18:59   ` Brian Foster
2013-12-12 20:56     ` Dave Chinner
2013-12-13 14:23       ` Brian Foster
2013-12-12  7:22 ` [PATCH 5/5] repair: limit auto-striding concurrency apprpriately Dave Chinner
2013-12-12 18:29   ` Christoph Hellwig
2013-12-12 21:00     ` Dave Chinner
2013-12-12 18:59   ` Brian Foster

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=20131212205311.GZ10988@dastard \
    --to=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=xfs@oss.sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.