From: Andrew Morton <akpm@osdl.org>
To: Ram Pai <linuxram@us.ibm.com>
Cc: nickpiggin@yahoo.com.au, peter@mysql.com, alexeyk@mysql.com,
linux-kernel@vger.kernel.org, axboe@suse.de
Subject: Re: Random file I/O regressions in 2.6
Date: Mon, 3 May 2004 23:29:28 -0700 [thread overview]
Message-ID: <20040503232928.1b13037c.akpm@osdl.org> (raw)
In-Reply-To: <1083631804.4544.16.camel@localhost.localdomain>
Ram Pai <linuxram@us.ibm.com> wrote:
>
> Sorry, If I am saying this again. I have checked the behaviour of the
> readahead code using my user level simulator as well as running some
> DSS benchmark and iozone benchmark. It generates a steady stream of
> large i/o for large-random-reads and should not exhibit the bad behavior
> that we are seeing. I feel this bad behavior is because of interleaved
> access by multiple thread.
you're right - the benchmark has multiple threads issuing concurrent
pread()s against the same fd. For some reason this mucks up the 2.6
readahead state more than 2.4's.
Putting a semaphore around do_generic_file_read() or maintaining the state
as below fixes it up.
I wonder if we should bother fixing this? I guess as long as the app is
using pread() it is a legitimate thing to be doing, so I guess we should...
--- 25/mm/filemap.c~readahead-seralisation 2004-05-03 23:14:43.399947720 -0700
+++ 25-akpm/mm/filemap.c 2004-05-03 23:14:43.404946960 -0700
@@ -612,7 +612,7 @@ EXPORT_SYMBOL(grab_cache_page_nowait);
* - note the struct file * is only passed for the use of readpage
*/
void do_generic_mapping_read(struct address_space *mapping,
- struct file_ra_state *ra,
+ struct file_ra_state *_ra,
struct file * filp,
loff_t *ppos,
read_descriptor_t * desc,
@@ -622,6 +622,7 @@ void do_generic_mapping_read(struct addr
unsigned long index, offset;
struct page *cached_page;
int error;
+ struct file_ra_state ra = *_ra;
cached_page = NULL;
index = *ppos >> PAGE_CACHE_SHIFT;
@@ -644,13 +645,13 @@ void do_generic_mapping_read(struct addr
}
cond_resched();
- page_cache_readahead(mapping, ra, filp, index);
+ page_cache_readahead(mapping, &ra, filp, index);
nr = nr - offset;
find_page:
page = find_get_page(mapping, index);
if (unlikely(page == NULL)) {
- handle_ra_miss(mapping, ra, index);
+ handle_ra_miss(mapping, &ra, index);
goto no_cached_page;
}
if (!PageUptodate(page))
@@ -752,6 +753,8 @@ no_cached_page:
goto readpage;
}
+ *_ra = ra;
+
*ppos = ((loff_t) index << PAGE_CACHE_SHIFT) + offset;
if (cached_page)
page_cache_release(cached_page);
_
next prev parent reply other threads:[~2004-05-04 6:30 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-02 19:57 Alexey Kopytov
2004-05-03 11:14 ` Nick Piggin
2004-05-03 18:08 ` Andrew Morton
2004-05-03 20:22 ` Ram Pai
2004-05-03 20:57 ` Andrew Morton
2004-05-03 21:37 ` Peter Zaitsev
2004-05-03 21:50 ` Ram Pai
2004-05-03 22:01 ` Peter Zaitsev
2004-05-03 21:59 ` Andrew Morton
2004-05-03 22:07 ` Ram Pai
2004-05-03 23:58 ` Nick Piggin
2004-05-04 0:10 ` Andrew Morton
2004-05-04 0:19 ` Nick Piggin
2004-05-04 0:50 ` Ram Pai
2004-05-04 6:29 ` Andrew Morton [this message]
2004-05-04 15:03 ` Ram Pai
2004-05-04 19:39 ` Ram Pai
2004-05-04 19:48 ` Andrew Morton
2004-05-04 19:58 ` Ram Pai
2004-05-04 21:51 ` Ram Pai
2004-05-04 22:29 ` Ram Pai
2004-05-04 23:01 ` Alexey Kopytov
2004-05-04 23:20 ` Andrew Morton
2004-05-05 22:04 ` Alexey Kopytov
2004-05-06 8:43 ` Andrew Morton
2004-05-06 18:13 ` Peter Zaitsev
2004-05-06 21:49 ` Andrew Morton
2004-05-06 23:49 ` Nick Piggin
2004-05-07 1:29 ` Peter Zaitsev
2004-05-10 19:50 ` Ram Pai
2004-05-10 20:21 ` Andrew Morton
2004-05-10 22:39 ` Ram Pai
2004-05-10 23:07 ` Andrew Morton
2004-05-11 20:51 ` Ram Pai
2004-05-11 21:17 ` Andrew Morton
2004-05-13 20:41 ` Ram Pai
2004-05-17 17:30 ` Random file I/O regressions in 2.6 [patch+results] Ram Pai
2004-05-20 1:06 ` Alexey Kopytov
2004-05-20 1:31 ` Ram Pai
2004-05-21 19:32 ` Alexey Kopytov
2004-05-20 5:49 ` Andrew Morton
2004-05-20 21:59 ` Andrew Morton
2004-05-20 22:23 ` Andrew Morton
2004-05-21 7:31 ` Nick Piggin
2004-05-21 7:50 ` Jens Axboe
2004-05-21 8:40 ` Nick Piggin
2004-05-21 8:56 ` Spam: " Andrew Morton
2004-05-21 22:24 ` Alexey Kopytov
2004-05-21 21:13 ` Alexey Kopytov
2004-05-26 4:43 ` Alexey Kopytov
2004-05-11 22:26 ` Random file I/O regressions in 2.6 Bill Davidsen
2004-05-04 1:15 ` Andrew Morton
2004-05-04 11:39 ` Nick Piggin
2004-05-04 8:27 ` Arjan van de Ven
2004-05-04 8:47 ` Andrew Morton
2004-05-04 8:50 ` Arjan van de Ven
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=20040503232928.1b13037c.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=alexeyk@mysql.com \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=nickpiggin@yahoo.com.au \
--cc=peter@mysql.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®