From: Steve Lord <lord@xfs.org>
To: David Chinner <dgc@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: Directories > 2GB
Date: Wed, 11 Oct 2006 11:49:10 -0500 [thread overview]
Message-ID: <452D2086.2020204@xfs.org> (raw)
In-Reply-To: <20061010233124.GX11034@melbourne.sgi.com>
David Chinner wrote:
> On Tue, Oct 10, 2006 at 10:19:04AM +0100, Christoph Hellwig wrote:
>> On Mon, Oct 09, 2006 at 09:15:28PM -0500, Steve Lord wrote:
>>> Hi Dave,
>>>
>>> My recollection is that it used to default to on, it was disabled
>>> because it needs to map the buffer into a single contiguous chunk
>>> of kernel memory. This was placing a lot of pressure on the memory
>>> remapping code, so we made it not default to on as reworking the
>>> code to deal with non contig memory was looking like a major
>>> effort.
>> Exactly. The code works but tends to go OOM pretty fast at least
>> when the dir blocksize code is bigger than the page size. I should
>> give the code a spin on my ppc box with 64k pages if it works better
>> there.
>
> The pagebuf code doesn't use high-order allocations anymore; it uses
> scatter lists and remapping to allow physically discontiguous pages
> in a multi-page buffer. That is, the pages are sourced via
> find_or_create_page() from the address space of the backing device,
> and then mapped via vmap() to provide a virtually contigous mapping
> of the multi-page buffer.
>
> So I don't think this problem exists anymore...
I was not referring to high order allocations here, but the overhead
of doing address space remapping every time a directory is accessed.
Steve
next prev parent reply other threads:[~2006-10-11 16:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-04 16:56 Directories > 2GB Andreas Dilger
2006-10-04 17:51 ` Dave Kleikamp
2006-10-04 19:09 ` Peter Grandi
2006-10-09 21:53 ` Steve Lord
2006-10-10 1:55 ` David Chinner
2006-10-10 2:07 ` Nathan Scott
2006-10-10 2:15 ` Steve Lord
2006-10-10 9:19 ` Christoph Hellwig
2006-10-10 23:31 ` David Chinner
2006-10-11 16:49 ` Steve Lord [this message]
2006-10-12 0:26 ` David Chinner
[not found] ` <452D2086.2020204__28695.6273987473$1160585745$gmane$org@xfs.org>
2006-10-16 18:17 ` Andi Kleen
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=452D2086.2020204@xfs.org \
--to=lord@xfs.org \
--cc=dgc@sgi.com \
--cc=hch@infradead.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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.