Peter Teoh wrote:
On Wed, Apr 2, 2008 at 10:58 AM, KOSAKI Motohiro
<[EMAIL PROTECTED]> 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......
Are you basing it on Least Recently Used? I seems to remember that Con
Konilias had added a swapping module to his staircase scheduler... if I
remember correctly, it was fairly controversial because it would swap
back in before the data was needed if the cache pressure was low and the
memory was freed back up; although I'm not sure if you want pursue
paying the swap price twice, it seems to make sense that the cost
doesn't count if the machine is idle anyways and you don't want to wait
for a double page fault (first for the page table and then for the data
itself) when you're requesting data. For some reason I think that
cache/allocated memory ratios should be a prime to non-prime
(composite? I need caffeine) ratio. Kinda' like how hash tables work
best when their sizes are prime... although I think that only applies
for certain types of sorts.
Anyways, Peter, have you looked at Cons code at all? He seemed to be
blazing trails, although I don't know if he was blazing them in the
correct direction or not.
Also, have you considered optimizing your lookups for least recently
used data? I think it's implemented as a linked list, and principle of
locality should apply such that you can probably jump over chunks
without checking them (as hot data is usually close to hot data). Just
a few wandering thoughts. What do you think?
