linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "yunfeng zhang" <zyf.zeroos@gmail.com>
To: "Valdis.Kletnieks@vt.edu" <Valdis.Kletnieks@vt.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Improvement on memory subsystem
Date: Wed, 19 Jul 2006 11:44:27 +0800	[thread overview]
Message-ID: <4df04b840607182044o2514d7ddi8893c268b759ca41@mail.gmail.com> (raw)
In-Reply-To: <200607181218.k6ICIgeS027067@turing-police.cc.vt.edu>

> On Tue, 18 Jul 2006 18:03:54 +0800, yunfeng zhang said:
>
> But wouldn't that end up causing a seek storm, rather than handling the pages
> in the order that minimizes the total seek distance, no matter where they are
> in memory? Remember - if you have a 2Ghz processor, and a disk that seeks in 1
> millisecond, every seek is (*very* roughly) about 2 million instructions.  So
> if we can burn 20 thousand instructions finding a read order that eliminates
> *one* seek, we're 1.98M instructions ahead.

Further sample is showd below

to page-fault (page-in operation) scan the pte triggering page-fault and its
following ptes in its VMA, if its followers are swap_entry_t type and their
relative offset is enough closer to the host pte, read them together.

to swap daemon (page-out operation), let's scan every pte of a VMA in the OS, if
we find an appropriate candidate, lock it and its following ptes if all ptes are
appropriate swap-out objects, then allocate a consecutive swap pages from swap
space, if we're success, do an efficient asynchronous IO operation; if we're
failed, shrink those ptes.

Isn't it right?

By the way, all improvements listed by me are introduced briefly, most of them
are complex, maybe only my documentation can descript them clearly.

  reply	other threads:[~2006-07-19  3:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-18 10:03 Improvement on memory subsystem yunfeng zhang
2006-07-18 12:18 ` Valdis.Kletnieks
2006-07-19  3:44   ` yunfeng zhang [this message]
2006-07-19  9:18   ` Ian Stirling
2006-07-19 14:56     ` Valdis.Kletnieks
2006-07-18 16:25 ` Pekka Enberg
2006-07-19  3:21   ` yunfeng zhang
2006-07-19  8:30     ` Pekka Enberg
2006-07-19 10:13       ` yunfeng zhang
2006-07-19 10:35         ` Pekka Enberg
2006-07-24  9:01 ` yunfeng zhang
2006-07-24 14:55   ` David Lang
2006-07-25  8:33     ` yunfeng zhang
2006-08-23 10:39 ` yunfeng zhang

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=4df04b840607182044o2514d7ddi8893c268b759ca41@mail.gmail.com \
    --to=zyf.zeroos@gmail.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).