From: Bart Samwel <bart@samwel.tk>
To: Andrew Morton <akpm@osdl.org>
Cc: felix-kernel@fefe.de, linux-kernel@vger.kernel.org
Subject: Re: Request: I/O request recording
Date: Mon, 26 Jan 2004 00:29:49 +0100 [thread overview]
Message-ID: <4014516D.5070409@samwel.tk> (raw)
In-Reply-To: <20040125150914.1583d487.akpm@osdl.org>
Andrew Morton wrote:
> Bart Samwel <bart@samwel.tk> wrote:
>
>>When I saw this thread I've fiddled for a bit with the block_dump
>> functionality that's in the laptop_mode patch. I wanted to see if it
>> could support a similar thing completely from user space (except for the
>> block_dump code, of course). I've written a small tool to generate a
>> complete file that lists tuples (sector, size, device) from the kernel
>> output in syslog; it parses all "READ block xxx" messages since the
>> last reboot. Putting this through sort -n -u delivers a nicely sorted
>> file, ready for optimized reading.
>>
>> Unfortunately I'm now stuck within the other part, which is reading the
>> pages back in memory at the next boot. It's not working, and I was
>> hoping someone here could take a look and tell me what I'm doing wrong.
>
> Linux caches disk data on a per-file basis. So if you preload pagecache
> via the /dev/hda1 "file", that is of no benefit to the /etc/passwd file.
> Each one has its own unique pagecache. When reading pages for /etc/passwd
> we don't go looking for the same disk blocks in the cache of /dev/hda1.
>
> Which is why the userspace cache preloading needs to know the pathnames of
> all the relevant files - it needs to open and read each one, applying
> knowledge of disk layout while doing it.
Hmmm, that explains why this didn't work. :( So if I wanted to do this
completely from user space using only block_dump data I'd probably have
to go through all files and find out if they had any blocks in common
with my preload set -- presuming there is a way to find that out, which
there probably isn't. That makes this idea pretty much useless, I'm
sorry to have bothered you with it.
-- Bart
next prev parent reply other threads:[~2004-01-25 23:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-24 18:10 Request: I/O request recording Felix von Leitner
2004-01-24 18:23 ` Valdis.Kletnieks
2004-01-24 18:26 ` Arjan van de Ven
2004-01-24 19:25 ` Ville Herva
2004-01-24 22:43 ` Arjan van de Ven
2004-01-24 20:11 ` Diego Calleja
2004-01-24 21:09 ` Ville Herva
2004-01-24 23:35 ` Andrew Morton
2004-01-24 23:53 ` Davide Libenzi
2004-01-25 0:03 ` Andrew Morton
2004-01-25 0:09 ` Davide Libenzi
2004-01-25 0:04 ` Valdis.Kletnieks
2004-01-25 0:10 ` Davide Libenzi
2004-01-25 12:26 ` Felipe Alfaro Solana
2004-01-25 22:59 ` Bart Samwel
2004-01-25 23:09 ` Andrew Morton
2004-01-25 23:29 ` Bart Samwel [this message]
2004-01-25 23:38 ` Andrew Morton
2004-01-26 0:23 ` Diego Calleja García
2004-01-26 0:32 ` Andrew Morton
2004-01-26 11:50 ` Bart Samwel
2004-01-26 11:57 ` Andrew Morton
2004-01-27 19:13 ` Bart Samwel
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=4014516D.5070409@samwel.tk \
--to=bart@samwel.tk \
--cc=akpm@osdl.org \
--cc=felix-kernel@fefe.de \
--cc=linux-kernel@vger.kernel.org \
/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.