From: Chuck Lever <cel@monkey.org>
To: "Benjamin C.R. LaHaise" <blah@kvack.org>
Cc: Linus Torvalds <torvalds@transmeta.com>, linux-mm@kvack.org
Subject: Re: [patch] mmap<->write deadlock fix, plus bug in block_write_zero_range
Date: Wed, 22 Dec 1999 10:58:33 -0500 (EST) [thread overview]
Message-ID: <Pine.BSO.4.10.9912221046420.20066-100000@funky.monkey.org> (raw)
In-Reply-To: <Pine.LNX.3.96.991222103000.22064A-100000@kanga.kvack.org>
On Wed, 22 Dec 1999, Benjamin C.R. LaHaise wrote:
> On Wed, 22 Dec 1999, Chuck Lever wrote:
> > i've tried this before several times. i could never get the system to
> > perform as well under benchmark load using find_page_nolock as when using
> > find_get_page. the throughput difference was about 5%, if i recall. i
> > haven't explained this to myself yet.
> >
> > perhaps a better fix would be to take out some of the page lock complexity
> > from filemap_nopage? dunno.
>
> Well, there certainly is a lot of code in page_cache_read /
> do_generic_file_read / filemap_nopage that is duplicate, and our policies
> across them are inconsistent.
when i started looking at mmap read-ahead and madvise, i noticed that
there was a lot of inconsistent code duplication, and thought it would be
a good thing to fold this stuff together. that's one reason i created the
"read_cluster_nonblocking" and "page_cache_read" functions. for example,
you can remove 20-40 lines of do_generic_file_read by replacing them with
one call to page_cache_read. or you could easily try clustered reads
there.
but notice you want to do something slightly different in
generic_file_write, so that code will probably need to stay.
> Here's my hypothesis about why find_page_nolock vs find_get_page makes a
> difference: using find_page_nolock means that we'll never do a
> run_task_queue(&tq_disk); to get our async readahead requests run. So, in
> theory, doing that in filemap_nopage will restore performance.
sounds like a reasonable explanation to me, and easy enough to test, even.
i'll give that a shot later today.
> Isn't
> there a way that the choice of when to run tq_disk could be made a bit
> less arbitrary?
i suppose there's a more *efficient* way of doing it, but i think running
the queue while waiting for a page is probably a good idea. in other
words, running the queue in find_get_page seems like a good idea to me.
what did you have in mind?
- Chuck Lever
--
corporate: <chuckl@netscape.com>
personal: <chucklever@netscape.net> or <cel@monkey.org>
The Linux Scalability project:
http://www.citi.umich.edu/projects/linux-scalability/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.nl.linux.org/Linux-MM/
next prev parent reply other threads:[~1999-12-22 15:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-12-22 5:58 [patch] mmap<->write deadlock fix, plus bug in block_write_zero_range Benjamin C.R. LaHaise
1999-12-22 15:08 ` Chuck Lever
1999-12-22 15:43 ` Benjamin C.R. LaHaise
1999-12-22 15:58 ` Chuck Lever [this message]
1999-12-23 4:00 ` Chuck Lever
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=Pine.BSO.4.10.9912221046420.20066-100000@funky.monkey.org \
--to=cel@monkey.org \
--cc=blah@kvack.org \
--cc=linux-mm@kvack.org \
--cc=torvalds@transmeta.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.