[lkml]   [2009]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] respect the referenced bit of KVM guest pages?
    On Wed, Aug 05, 2009 at 05:58:05PM +0200, Andrea Arcangeli wrote:
    > On Wed, Aug 05, 2009 at 10:40:58AM +0800, Wu Fengguang wrote:
    > > */
    > > - if ((vm_flags & VM_EXEC) && !PageAnon(page)) {
    > > + if ((vm_flags & VM_EXEC) || PageAnon(page)) {
    > > list_add(&page->lru, &l_active);
    > > continue;
    > > }
    > >
    > Please nuke the whole check and do an unconditional list_add;
    > continue; there.

    After some conversation it seems reactivating on large systems
    generates troubles to the VM as young bit have excessive time to be
    reactivated, giving troubles to shrink active list. I see that, so
    then the check should be still nuked, but the unconditional
    deactivation should happen instead. Otherwise it's trivial to put the
    VM to its knees and DoS it with a simple mmap of a file with MAP_EXEC
    as parameter of mmap. My whole point is that deciding if activating or
    deactivating pages can't be in function of VM_EXEC, and clearly it
    helps on desktops but then it probably is a signal that the VM isn't
    good enough by itself to identify the important working set using
    young bits and stuff on desktop systems, and if there's a good reason
    to not activate, we shouldn't activate the VM_EXEC either as anything
    and anybody can generate a file mapping with VM_EXEC set...

    Likely we need a cut-off point, if we detect it takes more than X
    seconds to scan the whole active list, we start ignoring young bits,
    as young bits don't provide any meaningful information then and they
    just hang the VM in preventing it to shrink active list and looping
    over it endlessy with million pages inside that list. But on small
    systems if inactive list is short it may be too quick to just clear
    the young bit and only giving it time to be re-enabled in inactive
    list. That may be the source of the problem. Actually I'm speculating
    here, because I barely understood that this is swapin... not sure
    exactly what this regression is about but testing the patch posted is
    good idea and it will tell us if we just need to dynamically
    differentiating the algorithm between large and small systems and start
    ignoring young bits only at some point.

     \ /
      Last update: 2009-08-06 12:11    [W:0.026 / U:7.880 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site