From: Wu Fengguang <wfg@mail.ustc.edu.cn>
To: Linda Walsh <lkml@tlinx.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] kernel facilities for cache prefetching
Date: Fri, 5 May 2006 23:20:07 +0800 [thread overview]
Message-ID: <346842402.09691@ustc.edu.cn> (raw)
Message-ID: <20060505152007.GB6134@mail.ustc.edu.cn> (raw)
In-Reply-To: <445A4E91.1050802@tlinx.org>
On Thu, May 04, 2006 at 11:57:21AM -0700, Linda Walsh wrote:
> Wu Fengguang wrote:
> >> b) Be "dynamic"; "Trace" (record (dev&blockno/range) blocks
> >>starting ASAP after system boot and continuing for some "configurable"
> >>number of seconds past reaching the desired "run-level" (coinciding with
> >>initial disk quiescence). Save as "configurable" (~6-8?) number of
> >>traces to allow finding the common initial subset of blocks needed.
> >>
> >
> >It is a alternative way of doing the same job: more precise, with more
> >complexity and more overhead. However the 'blockno' way is not so
> >tasteful.
> >
> ----
> Maybe not so tasteful to you, but it is an alternate path that
> circumvents unnecessary i/o redirections. An additional optimization
Yes, it's about the choice of the overhead/generalization that
indirections bring about.
> is to have a "cache" of frequently used "system applications" that have
> their pathnames registered, so no run-time seaching of the user PATH
> is necessary.
The facility is already there: it is called dcache.
> >I guess poor man's defrag would be good enough for the seeking storm.
> >
> ---
> I disagree. The "poor man's defrag, as you call it, puts entire files
> into contiguous sections -- each of which will have to be referenced by
> following
> a PATH and directory chain. The optimization I'm talking about would
> only store
> the referenced data-blocks actually used in the files. This would allow a
> directy read into memory of a *bunch* of needed sectors while not including
> sectors from the same files that are not actually read from during the
> boot *or*
> app. initialization process.
The seek storm is mostly caused by small files(that are read in wholes),
and the corresponding scattered dir/inode buffers. By moving these
files to one single directory, both the file data/inode buffers are
kept continuous enough.
> ^** -- "somewhere", it _seems_, the physical, device relative sector
> must be resolved. If it is not, how is i/o-block buffer consistency
> maintained when the user references "device "hda", sector "1000", then
> the same sector as "hda1", sector 500, and also as file "/etc/passwd",
> sector 0? _If_ cache consistency is maintained (and I _assume_^**2
> it is), they all need to be mapped to a physical sector at some point.
>
> ^**2 - Use of assumption noted; feel free to correct me and tell me
> this isn't the case if linux doesn't maintain disk-block cache
> consistency.
The linux cache model is something like:
physical drive file /dev/hda1
| <-----------------> |
file /bin/ls | |
|<---------------------> | |
|<---------------------> | |
| <-----------------> |
| |
| |
file /boot/vmlinuz | |
|<---------------------> | |
| | |
| | |
|<---------------------> | |
| <-----------------> |
| |
| |
| |
As opposed to this one:
file /dev/hda1 physical drive
| <-----------------> |
file /bin/ls | |
|<---------------------> | |
|<---------------------> | |
| <-----------------> |
| |
| |
file /boot/vmlinuz | |
|<---------------------> | |
| | |
| | |
|<---------------------> | |
| <-----------------> |
| |
| |
| |
Wu
next prev parent reply other threads:[~2006-05-05 15:20 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060502075049.GA5000@mail.ustc.edu.cn>
2006-05-02 7:50 ` [RFC] kernel facilities for cache prefetching Wu Fengguang
2006-05-02 12:46 ` Diego Calleja
[not found] ` <20060502144203.GA10594@mail.ustc.edu.cn>
2006-05-02 14:42 ` Wu Fengguang
2006-05-02 16:07 ` Diego Calleja
[not found] ` <20060503064503.GA4781@mail.ustc.edu.cn>
2006-05-03 6:45 ` Wu Fengguang
2006-05-03 18:14 ` Diego Calleja
2006-05-03 23:39 ` Zan Lynx
2006-05-04 1:37 ` Diego Calleja
2006-05-02 15:55 ` Linus Torvalds
2006-05-02 16:35 ` Andi Kleen
[not found] ` <20060503041106.GC5915@mail.ustc.edu.cn>
2006-05-03 4:11 ` Wu Fengguang
2006-05-03 17:28 ` Badari Pulavarty
[not found] ` <346733486.30800@ustc.edu.cn>
2006-05-04 15:03 ` Linus Torvalds
2006-05-04 16:57 ` Badari Pulavarty
[not found] ` <20060505144451.GA6134@mail.ustc.edu.cn>
2006-05-05 14:44 ` Wu Fengguang
[not found] ` <20060503071325.GC4781@mail.ustc.edu.cn>
2006-05-03 7:13 ` Wu Fengguang
2006-05-03 12:59 ` Nikita Danilov
2006-05-03 22:20 ` Rik van Riel
[not found] ` <20060506011125.GA9099@mail.ustc.edu.cn>
2006-05-06 1:11 ` Wu Fengguang
2006-05-04 0:28 ` Linda Walsh
2006-05-04 1:31 ` Linus Torvalds
2006-05-04 7:08 ` Ph. Marek
2006-05-04 7:33 ` Arjan van de Ven
[not found] ` <20060504121454.GB6008@mail.ustc.edu.cn>
2006-05-04 12:14 ` Wu Fengguang
2006-05-04 12:34 ` Arjan van de Ven
2006-05-03 21:45 ` Linda Walsh
[not found] ` <20060504121212.GA6008@mail.ustc.edu.cn>
2006-05-04 12:12 ` Wu Fengguang
2006-05-04 18:57 ` Linda Walsh
[not found] ` <20060505152007.GB6134@mail.ustc.edu.cn>
2006-05-05 15:20 ` Wu Fengguang [this message]
2006-05-04 9:02 ` Helge Hafting
2006-05-02 7:58 ` Arjan van de Ven
[not found] ` <20060502080619.GA5406@mail.ustc.edu.cn>
2006-05-02 8:06 ` Wu Fengguang
2006-05-02 8:30 ` Arjan van de Ven
[not found] ` <20060502085325.GA9190@mail.ustc.edu.cn>
2006-05-02 8:53 ` Wu Fengguang
2006-05-06 6:49 ` Denis Vlasenko
2006-05-02 8:55 ` Arjan van de Ven
2006-05-02 11:39 ` Jan Engelhardt
[not found] ` <20060502114853.GA9983@mail.ustc.edu.cn>
2006-05-02 11:48 ` Wu Fengguang
2006-05-02 22:03 ` Dave Jones
2006-05-02 8:09 ` Jens Axboe
[not found] ` <20060502082009.GA9038@mail.ustc.edu.cn>
2006-05-02 8:20 ` Wu Fengguang
2006-05-03 22:05 ` Benjamin LaHaise
2006-05-02 19:10 ` Pavel Machek
2006-05-02 23:36 ` Nigel Cunningham
[not found] ` <20060503023505.GB5915@mail.ustc.edu.cn>
2006-05-03 2:35 ` Wu Fengguang
[not found] ` <20060503023223.GA5915@mail.ustc.edu.cn>
2006-05-03 2:32 ` Wu Fengguang
[not found] ` <20060503071948.GD4781@mail.ustc.edu.cn>
2006-05-03 7:19 ` Wu Fengguang
[not found] ` <20060504122830.GA6205@mail.ustc.edu.cn>
2006-05-04 12:28 ` Wu Fengguang
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=346842402.09691@ustc.edu.cn \
--to=wfg@mail.ustc.edu.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@tlinx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox