linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Peter Teoh" <htmldeveloper@gmail.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Mulyadi Santosa <mulyadi.santosa@gmail.com>,
	Kernel Newbies <kernelnewbies@nl.linux.org>,
	linux-mm@kvack.org, Rik van Riel <riel@surriel.com>
Subject: Re: RFC: swaptrace tool
Date: Wed, 2 Apr 2008 11:28:49 +0800	[thread overview]
Message-ID: <804dabb00804012028j41acca2ya69081bb92c6788d@mail.gmail.com> (raw)
In-Reply-To: <20080402115000.E130.KOSAKI.MOTOHIRO@jp.fujitsu.com>

On Wed, Apr 2, 2008 at 10:58 AM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
> Hi
>
>
>  > >  hmm,
>  > >  I can't find it from mailing list log.
>  > >  Could you recall subject of that patch?
>  >
>  > here is the URL http://lkml.org/lkml/2006/8/4/77
>
>  Oh! thanks.
>  but, this patch only get per process # of swap pages.
>
>  and the following patch is merged -mm before a while.
>  http://marc.info/?l=linux-kernel&m=120654533828554&w=2
>
>  thus, now we have its capability via /proc/pid/smap.
>
>  in my understanding, originally requirement wanted following tuple.
>
>   - destination begin offset / size
>   - source begin offset / size
>   - process/task
>
>

ah...yes...exactly.   but Mulyadi patch is good headstart for me to
focus on - to see how it can be tweaked for extracting out this lean
information.   lean because as compared with blktrace, it is just
focusing on the BOUNDARY of the swapspace being written or read
(whereas blktrace will include the data itself).....every seconds or
every minutes, snapshot of these kind of information will allow us to
see how the swapspace is dynamically being used....and then we can
then design a good page replacement policy or swapspace usage
algorithm.....eg, to maximize the clustering factor when paging.
sort of a simulation tool......

-- 
Regards,
Peter Teoh

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ

  reply	other threads:[~2008-04-02  3:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-01  8:54 Peter Teoh
2008-04-01  9:31 ` Peter Chubb
2008-04-01 10:26 ` Mulyadi Santosa
2008-04-01 12:27   ` KOSAKI Motohiro
2008-04-02  1:23     ` Mulyadi Santosa
2008-04-02  2:58       ` KOSAKI Motohiro
2008-04-02  3:28         ` Peter Teoh [this message]
     [not found]           ` <47F301E2.6060403@gmail.com>
2008-04-02  5:52             ` Mulyadi Santosa
     [not found]         ` <f284c33d0804012249vb16325fpb9946487140c5905@mail.gmail.com>
2008-04-02  7:52           ` Peter Teoh
2008-04-02  7:55             ` KOSAKI Motohiro
2008-04-02  8:50               ` Peter Teoh

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=804dabb00804012028j41acca2ya69081bb92c6788d@mail.gmail.com \
    --to=htmldeveloper@gmail.com \
    --cc=kernelnewbies@nl.linux.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=mulyadi.santosa@gmail.com \
    --cc=riel@surriel.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