Evicting Anonymous pages.

[rohan puri]

On Tue, Sep 27, 2011 at 11:56 PM, Prateek Sharma <prateek3.14 at gmail.com>wrote:

> On Tue, Sep 27, 2011 at 11:42 PM, Mulyadi Santosa
> <mulyadi.santosa at gmail.com> wrote:
> > Hi :)
> >
> > On Wed, Sep 28, 2011 at 00:14, Prateek Sharma <prateek3.14 at gmail.com>
> wrote:
> >> Hello everyone,
> >>  I am trying to understand the kernel page frame reclaiming
> >> mechanism, but one thing's bothering me:
> >> How does the kernel 'know' which anonymous pages to evict? In the LRU
> >> scheme,  'referenced/used' information for each page is required
> >> (AFAIK). But anonymous pages can be used by user processes 'at any
> >> time' without the kernel knowing about it.
>
(AFAIK) Anonymous pages do not correspond to any file. It may be part of a
program's data area or stack & is written to the swap area.
When a process tries to access the anonymous pages it notifies the swapper
to get back the swap area in mem. In case of a process which holds the swap
token, swapping of anonymous pages is avoided.

> >
> > Same question hog my mind too so far :)
> >
> > The only satisfying self answer I could deduce is:
> > kernel can't track every access to pages when you do it like e.g mov
> > %ax,8(%esp). What kernel could track is when you access data via
> > wrappers. I forgot which ones, but remember some of them are updating
> > those "referenced" etc flags. Perhaps something like get_pages or
> > alike.
> >
> > --
> > regards,
> >
> > Mulyadi Santosa
> > Freelance Linux trainer and consultant
> >
>
> page_referenced_anon is called for anonymous pages by page_referenced.
> And as far as i could figure out, that uses mmu_notifiers. [calls
> pmdp_clear_flush_young_notify]
>
> Whether every anonymous page access is trapped, or only a few of them,
> i have not yet figured out.
>
> Linux-mm seems to be full of magic!
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110928/ee21acb6/attachment.html