[lkml]   [2009]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
On Sat, May 16, 2009 at 05:28:58PM +0800, Wu Fengguang wrote:
> [trivial update on comment text, according to Rik's comment]
> --
> vmscan: make mapped executable pages the first class citizen
> Protect referenced PROT_EXEC mapped pages from being deactivated.
> PROT_EXEC(or its internal presentation VM_EXEC) pages normally belong to some
> currently running executables and their linked libraries, they shall really be
> cached aggressively to provide good user experiences.
> Thanks to Johannes Weiner for the advice to reuse the VMA walk in
> page_referenced() to get the PROT_EXEC bit.
> [more details]
> ( The consequences of this patch will have to be discussed together with
> Rik van Riel's recent patch "vmscan: evict use-once pages first". )
> ( Some of the good points and insights are taken into this changelog.
> Thanks to all the involved people for the great LKML discussions. )
> the problem
> -----------
> For a typical desktop, the most precious working set is composed of
> *actively accessed*
> (1) memory mapped executables
> (2) and their anonymous pages
> (3) and other files
> (4) and the dcache/icache/.. slabs
> while the least important data are
> (5) infrequently used or use-once files
> For a typical desktop, one major problem is busty and large amount of (5)
> use-once files flushing out the working set.
> Inside the working set, (4) dcache/icache have already been too sticky ;-)
> So we only have to care (2) anonymous and (1)(3) file pages.
> anonymous pages
> ---------------
> Anonymous pages are effectively immune to the streaming IO attack, because we
> now have separate file/anon LRU lists. When the use-once files crowd into the
> file LRU, the list's "quality" is significantly lowered. Therefore the scan
> balance policy in get_scan_ratio() will choose to scan the (low quality) file
> LRU much more frequently than the anon LRU.
> file pages
> ----------
> Rik proposed to *not* scan the active file LRU when the inactive list grows
> larger than active list. This guarantees that when there are use-once streaming
> IO, and the working set is not too large(so that active_size < inactive_size),
> the active file LRU will *not* be scanned at all. So the not-too-large working
> set can be well protected.
> But there are also situations where the file working set is a bit large so that
> (active_size >= inactive_size), or the streaming IOs are not purely use-once.
> In these cases, the active list will be scanned slowly. Because the current
> shrink_active_list() policy is to deactivate active pages regardless of their
> referenced bits. The deactivated pages become susceptible to the streaming IO
> attack: the inactive list could be scanned fast (500MB / 50MBps = 10s) so that
> the deactivated pages don't have enough time to get re-referenced. Because a
> user tend to switch between windows in intervals from seconds to minutes.
> This patch holds mapped executable pages in the active list as long as they
> are referenced during each full scan of the active list. Because the active
> list is normally scanned much slower, they get longer grace time (eg. 100s)
> for further references, which better matches the pace of user operations.
> Therefore this patch greatly prolongs the in-cache time of executable code,
> when there are moderate memory pressures.
> before patch: guaranteed to be cached if reference intervals < I
> after patch: guaranteed to be cached if reference intervals < I+A
> (except when randomly reclaimed by the lumpy reclaim)
> where
> A = time to fully scan the active file LRU
> I = time to fully scan the inactive file LRU
> Note that normally A >> I.
> side effects
> ------------
> This patch is safe in general, it restores the pre-2.6.28 mmap() behavior
> but in a much smaller and well targeted scope.
> One may worry about some one to abuse the PROT_EXEC heuristic. But as
> Andrew Morton stated, there are other tricks to getting that sort of boost.
> Another concern is the PROT_EXEC mapped pages growing large in rare cases,
> and therefore hurting reclaim efficiency. But a sane application targeted for
> large audience will never use PROT_EXEC for data mappings. If some home made
> application tries to abuse that bit, it shall be aware of the consequences.
> If it is abused to scale of 2/3 total memory, it gains nothing but overheads.
> CC: Elladan <>
> CC: Nick Piggin <>
> CC: Johannes Weiner <>
> CC: Christoph Lameter <>
> CC: KOSAKI Motohiro <>
> Acked-by: Peter Zijlstra <>
> Acked-by: Rik van Riel <>
> Signed-off-by: Wu Fengguang <>

Reviewed-by: Johannes Weiner <>

 \ /
  Last update: 2009-05-16 15:23    [W:0.140 / U:12.716 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site