lkml.org 
[lkml]   [2009]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
    From
    On Sat, May 16, 2009 at 6:28 PM, Wu Fengguang <fengguang.wu@intel.com> 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 <elladan@eskimo.com>
    > CC: Nick Piggin <npiggin@suse.de>
    > CC: Johannes Weiner <hannes@cmpxchg.org>
    > CC: Christoph Lameter <cl@linux-foundation.org>
    > CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    > Acked-by: Peter Zijlstra <peterz@infradead.org>
    > Acked-by: Rik van Riel <riel@redhat.com>
    > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>

    Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2009-05-17 02:41    [W:0.030 / U:0.536 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site