All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Kendall <wkendall@sgi.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH v3 4/9] xfsrestore: mmap dirent names for faster lookups
Date: Wed, 17 Nov 2010 11:57:09 -0600	[thread overview]
Message-ID: <4CE41775.6080509@sgi.com> (raw)
In-Reply-To: <20101117093402.GG17317@infradead.org>

On 11/17/2010 03:34 AM, Christoph Hellwig wrote:
> On Tue, Nov 16, 2010 at 09:05:06AM -0600, wkendall@sgi.com wrote:
>> Pathname resolution in xfsrestore is about 4x faster if the file
>> containing dirent names ("namreg") is memory mapped.  If xfsrestore is
>> unable to map the file (e.g., due to virtual memory constraints)
>> fallback to the existing seek-and-read approach.
>>
>> The file is mapped after all directory entries have been written to
>> the "namreg" file. If the caller tries to add additional entries after
>> the file has been mapped, it will be unmapped and restore will resort
>> back to seek-and-read lookups.
>>
>> Signed-off-by: Bill Kendall<wkendall@sgi.com>
>>
>> Reviewed-by: Alex Elder<aelder@sgi.com>
>
> Generally looks good to me, but I really hate how namreg_map/unmap
> are hidden under namreg_add/flush.  As a start instead of adding the
> done_adding argument we can easily move the explicit map to the one
> caller wanting it, similarly namreg_unmap could be moved to namreg_add,
> that is manage to mapping/unmapping explicitly.

I'll rework this.

>
> In fact I'm not sure what the point of the unmap/map cycles is.  At
> least in Linux concurrent buffer writes and mmap reads are coherent.

Adding an entry extends the file beyond what is mapped. The unmap
code was merely defensive, in case namreg_add is called somewhere
after the file is mapped. I spent some time looking at the callers,
and all namreg_adds occur before the file is mapped. namreg_del is
called after the file is mapped, but as it doesn't do anything this
is not a problem. I'll remove the unmap code.

Bill

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

  reply	other threads:[~2010-11-17 17:55 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-16 15:05 [PATCH v3 0/9] xfsrestore dirent limitations and scaling issues wkendall
2010-11-16 15:05 ` [PATCH v3 1/9] xfsrestore: turn off NODECHK wkendall
2010-11-17  9:20   ` Christoph Hellwig
2010-11-16 15:05 ` [PATCH v3 2/9] xfsrestore: change nrh_t from 32 to 64 bits wkendall
2010-11-17  9:23   ` Christoph Hellwig
2010-11-16 15:05 ` [PATCH v3 3/9] xfsrestore: cache path lookups wkendall
2010-11-17  9:24   ` Christoph Hellwig
2010-11-16 15:05 ` [PATCH v3 4/9] xfsrestore: mmap dirent names for faster lookups wkendall
2010-11-17  9:34   ` Christoph Hellwig
2010-11-17 17:57     ` Bill Kendall [this message]
2010-11-16 15:05 ` [PATCH v3 5/9] xfsrestore: cleanup node allocation wkendall
2010-11-16 15:05 ` [PATCH v3 6/9] xfsrestore: fix node table setup wkendall
2010-11-16 15:05 ` [PATCH v3 7/9] xfsrestore: make node lookup more efficient wkendall
2010-11-16 19:20   ` Alex Elder
2010-11-16 15:05 ` [PATCH v3 8/9] xfsrestore: remove nix_t wkendall
2010-11-17  9:37   ` Christoph Hellwig
2010-11-16 15:05 ` [PATCH v3 9/9] xfsrestore: check for compatible xfsrestore wkendall
2010-11-17  9:38   ` Christoph Hellwig
2010-11-17 15:31     ` Bill Kendall
2010-11-23 13:44       ` Christoph Hellwig
2010-11-16 19:21 ` [PATCH v3 0/9] xfsrestore dirent limitations and scaling issues Alex Elder

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=4CE41775.6080509@sgi.com \
    --to=wkendall@sgi.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.