On Tue, 18 Jul 2006, Peter Zijlstra wrote:
> > I thought we wanted to just track the number of unmapped clean pages and
> > insure that they do not go under a certain limit? That would not require
> > any locking changes but just a new zoned counter and a check in the dirty
> > handling path.
>
> The problem I see with that is that we cannot create new unmapped clean
> pages. Where will we get new pages to satisfy our demand when there is
> nothing mmap'ed.
Hmmm... I am not sure that we both have this straight yet.
Adding logic to determine the number of clean pages is not necessary. The
number of clean pages in the pagecache can be determined by:
global_page_state(NR_FILE_PAGES) - global_page_state(NR_FILE_DIRTY)
That number can be increased by writeout and so I think we want this to
be checked in the throttling path. Swapout is only useful for
anonymous pages. Dirty anonymous pages are not tracked and do not
contribute to the NR_FILE_DIRTY (formerly nr_dirty). We only track
the number of anonymous pages in NR_ANON_PAGES. Swapout could be used
to reduce NR_ANON_PAGES if memory becomes tight.
The intend of insuring that a certain number of clean pages exist seems to
be to guarantee that a certain amount of memory is freeable without
having to go through a filesystem.
Pages that are available without file system activity are:
1. The already free pages.
2. The clean pagecache pages.
For a zone this is
zone->free_pages + zone_page_state(zone, NR_FILE_PAGES) -
zone_page_state(zone, NR_FILE_DIRTY)
If this goes below a certain limit then we either have to:
1. If NR_FILE_DIRTY is significant then we can increase the number
of reclaimable pages by writing them out.
2. If NR_FILE_DIRTY and NR_FILE_PAGES are low then writeout does
not help us. NR_ANON_PAGES is likely big. So we could swap some
anonymous pages out to increase zone->free_pages instead. Performance
wise this is a bad move. So we should prefer writeout.
However, the above scheme assumes that all pagecache pages can ne
unmapped if necessary. This may not be desirable since we may then
have no executable pages available anymore and create a significant
amount of disk traffic. If we would track the number of dirty unmapped
pages (by addding NR_UNMAPPED_DIRTY) then we could guarantee available
memory that would leave the pages in use by processes alone.
If we impose a limit on the number of free pages + the number of unmapped
clean pagecache pages then we have a reserve memory pool that can be
accessed without too much impact on performance. Its basically another
trigger for writeout.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
