Peter Teoh wrote:
On Wed, Apr 2, 2008 at 10:58 AM, KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx> 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/taskah...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? |
