From: Phillip Susi <psusi@ubuntu.com>
To: Theodore Ts'o <tytso@mit.edu>, Andreas Dilger <adilger@dilger.ca>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 2/2] libext2fs/e2fsck: implement metadata prefetching
Date: Thu, 27 Feb 2014 12:03:56 -0500 [thread overview]
Message-ID: <530F6FFC.4040903@ubuntu.com> (raw)
In-Reply-To: <20140131135325.GF7118@thunk.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 1/31/2014 8:53 AM, Theodore Ts'o wrote:
> Something that we might need to go to in the future is instead of
> using mmap(), to maintain our own explicit buffer cache inside
> unix_io, and use direct I/O to avoid caching the disk blocks
> twice. Then when we use a single-threaded disk prefetcher, managed
> by the unix_io, it will know when a particular I/O request has
> completed, and more importantly, if there is a synchronous read
> request coming in from main body of the program, it can stop
> prefetching and allow the higher priority read to complete. We can
> also experiment with how many threads might make sense --- even
> with an HDD, using multiple threads so that we can take advantage
> of NCQ might still be a win.
Why build your own cache instead of letting the kernel take care of
it? I believe the IO elevator already gives preferential treatment
to blocking reads so just using readahead() to prefetch and sticking
with plain old read() should work nicely.
> Finally, if we are managing our own buffer cache, we should
> consider adding a bforget method to the I/O manager. That way
> e2fsck can give hints to the caching layer that a block isn't
> needed any more. If it is in the cache, it can be dropped, to free
> memory, and if it is still on the to-be-prefetched list it should
> also be dropped. (Of course, if a block is on the to-be-prefetched
> list, and a synchronous read request comes in for that block, we
> should have dropped it from the to-be-prefetched list at that
> point.) The main use for having a bforget method is for the most
> part, once we are done scanning a non-directory extent tree block,
> we won't be needing it again.
Good idea, but this also could just be translated to posix_fadvise to
have the kernel drop the pages from the cache.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTD2/8AAoJEI5FoCIzSKrwN9QIAKKyOssDAoy6Zab7w+j6aXdH
f8Lzw/+WWevPpvX1o9SakQXVYejkiZBcEhJ/NrtQoDzQjesrERpKIj7m+Yb2blaQ
VYu9hj21ReVYngmmOlUHL9LJJtfwGptyO3SGvuSZv3NooMjEu51tCXxHLxONaYAb
SqvRBVH57E7hY1HckKTbD14YleKn/SD7peNIp1KP39zQw1soR83+oHh2qZ3Zaq7E
fa/UG7tnIMcOjHghacr83LA7XW+sQYn8pDeAmw38SKe+uiHvcqjzych6lQlKLw19
pKdzERd8zaPsiS2y4og/RzWZHolohiDp67cWRncYKm3ai2w4KbU9KXlQHa/6Fy0=
=orjY
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2014-02-27 17:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-30 23:50 [INSANE RFC PATCH 0/2] e2fsck metadata prefetch Darrick J. Wong
2014-01-30 23:50 ` [PATCH 1/2] libext2fs: mmap io manager Darrick J. Wong
2014-01-30 23:50 ` [PATCH 2/2] libext2fs/e2fsck: implement metadata prefetching Darrick J. Wong
[not found] ` <45DEEA58-69FD-42EF-BB51-1A8D80000469@dilger.ca>
2014-01-31 13:53 ` Theodore Ts'o
2014-02-01 8:16 ` Darrick J. Wong
2014-02-27 17:03 ` Phillip Susi [this message]
2014-02-27 18:31 ` Darrick J. Wong
2014-02-28 2:28 ` Theodore Ts'o
2014-02-28 18:54 ` Andreas Dilger
2014-02-28 20:18 ` Darrick J. Wong
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=530F6FFC.4040903@ubuntu.com \
--to=psusi@ubuntu.com \
--cc=adilger@dilger.ca \
--cc=darrick.wong@oracle.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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.