Is: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-admin@xenproject.org: [linux-4.1 bisection] complete test-amd64-i386-qemut-rhel6hvm-amd]

Is: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-admin@xenproject.org: [linux-4.1 bisection] complete test-amd64-i386-qemut-rhel6hvm-amd]

[Konrad Rzeszutek Wilk]

Hey Lukasz,

We found that your patch in the automated Xen test-case ends up
OOMing the box when trying to install guests. This worked prior
to your patch.

See serial log:
http://logs.test-lab.xenproject.org/osstest/logs/97597/test-amd64-i386-qemut-rhel6hvm-amd/serial-pinot0.log

Would it be OK to revert this patch from the stable trees?

Thanks.
----- Forwarded message from osstest service owner <osstest-admin@xenproject.org> -----

Date: Mon, 18 Jul 2016 13:49:13 +0000
From: osstest service owner <osstest-admin@xenproject.org>
To: xen-devel@lists.xensource.com, osstest-admin@xenproject.org
Subject: [Xen-devel] [linux-4.1 bisection] complete test-amd64-i386-qemut-rhel6hvm-amd

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemut-rhel6hvm-amd
testid redhat-install

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
  Bug introduced:  c5ad33184354260be6d05de57e46a5498692f6d6
  Bug not present: c5bcec6cbcbf520f088dc7939934bbf10c20c5a5
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/97597/


  commit c5ad33184354260be6d05de57e46a5498692f6d6
  Author: Lukasz Odzioba <lukasz.odzioba@intel.com>
  Date:   Fri Jun 24 14:50:01 2016 -0700
  
      mm/swap.c: flush lru pvecs on compound page arrival
      
      [ Upstream commit 8f182270dfec432e93fae14f9208a6b9af01009f ]
      
      Currently we can have compound pages held on per cpu pagevecs, which
      leads to a lot of memory unavailable for reclaim when needed.  In the
      systems with hundreads of processors it can be GBs of memory.
      
      On of the way of reproducing the problem is to not call munmap
      explicitly on all mapped regions (i.e.  after receiving SIGTERM).  After
      that some pages (with THP enabled also huge pages) may end up on
      lru_add_pvec, example below.
      
        void main() {
        #pragma omp parallel
        {
      	size_t size = 55 * 1000 * 1000; // smaller than  MEM/CPUS
      	void *p = mmap(NULL, size, PROT_READ | PROT_WRITE,
      		MAP_PRIVATE | MAP_ANONYMOUS , -1, 0);
      	if (p != MAP_FAILED)
      		memset(p, 0, size);
      	//munmap(p, size); // uncomment to make the problem go away
        }
        }
      
      When we run it with THP enabled it will leave significant amount of
      memory on lru_add_pvec.  This memory will be not reclaimed if we hit
      OOM, so when we run above program in a loop:
      
      	for i in `seq 100`; do ./a.out; done
      
      many processes (95% in my case) will be killed by OOM.
      
      The primary point of the LRU add cache is to save the zone lru_lock
      contention with a hope that more pages will belong to the same zone and
      so their addition can be batched.  The huge page is already a form of
      batched addition (it will add 512 worth of memory in one go) so skipping
      the batching seems like a safer option when compared to a potential
      excess in the caching which can be quite large and much harder to fix
      because lru_add_drain_all is way to expensive and it is not really clear
      what would be a good moment to call it.
      
      Similarly we can reproduce the problem on lru_deactivate_pvec by adding:
      madvise(p, size, MADV_FREE); after memset.
      
      This patch flushes lru pvecs on compound page arrival making the problem
      less severe - after applying it kill rate of above example drops to 0%,
      due to reducing maximum amount of memory held on pvec from 28MB (with
      THP) to 56kB per CPU.
      
      Suggested-by: Michal Hocko <mhocko@suse.com>
      Link: http://lkml.kernel.org/r/1466180198-18854-1-git-send-email-lukasz.odzioba@intel.com
      Signed-off-by: Lukasz Odzioba <lukasz.odzioba@intel.com>
      Acked-by: Michal Hocko <mhocko@suse.com>
      Cc: Kirill Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Vladimir Davydov <vdavydov@parallels.com>
      Cc: Ming Li <mingli199x@qq.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: Sasha Levin <sasha.levin@oracle.com>


For bisection revision-tuple graph see:
   http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.1/test-amd64-i386-qemut-rhel6hvm-amd.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-4.1/test-amd64-i386-qemut-rhel6hvm-amd.redhat-install --summary-out=tmp/97597.bisection-summary --basis-template=96211 --blessings=real,real-bisect linux-4.1 test-amd64-i386-qemut-rhel6hvm-amd redhat-install
Searching for failure / basis pass:
 97496 fail [host=pinot0] / 96211 ok.
Failure / basis pass flights: 97496 / 96211
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 5880876e94699ce010554f483ccf0009997955ca c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f b48be35ac86cd6369124cf06ca3006d086095297
Basis pass 95123c0b81d9478b8155fe15093b88f57ef7d0bd c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 91b26a35914176db4d19dc145bc6e2db62ee7a2c
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#95123c0b81d9478b8155fe15093b88f57ef7d0bd-5880876e94699ce010554f483ccf0009997955ca git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#6e20809727261599e8527c456eb078c0e89139a1-6e20809727261599e8527c456eb078c0e89139a1 git://xenbits.xen.org/qemu-xen.git#44a072f0de0d57c95c2212bbce02888832b7b74f-44a072f0de0d57c95c2212bbce02888832b7b74f git://xenbits.xen.org/xen.git#91b26a35914176db4d19dc145bc6e2db62ee7a2c-b48be35ac86cd6369124cf06ca3006d086095297
Loaded 2001 nodes in revision graph
Searching for test results:
 96211 pass 95123c0b81d9478b8155fe15093b88f57ef7d0bd c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 91b26a35914176db4d19dc145bc6e2db62ee7a2c
 96160 [host=pinot1]
 96183 [host=rimava1]
 97279 fail irrelevant
 97434 fail irrelevant
 97394 fail irrelevant
 97523 fail 67eab3249eacc0861cf57f6d929e66bf78159379 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
 97537 pass 691c507ec01fa0cab2a9cfb5bd4398ddd5480a8a c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
 97497 pass 95123c0b81d9478b8155fe15093b88f57ef7d0bd c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 91b26a35914176db4d19dc145bc6e2db62ee7a2c
 97556 fail 5880876e94699ce010554f483ccf0009997955ca c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f b48be35ac86cd6369124cf06ca3006d086095297
 97496 fail 5880876e94699ce010554f483ccf0009997955ca c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f b48be35ac86cd6369124cf06ca3006d086095297
 97518 fail irrelevant
 97529 pass 4a088cba60485acbdceee2c3f903e7b0c7846737 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
 97550 fail d4b08964d00a0b99e999a2bb1ce417e54b5c607f c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
 97543 fail b5ba0d06632445b3810b50093cd22a2ab06900de c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
 97566 pass c5bcec6cbcbf520f088dc7939934bbf10c20c5a5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
 97573 fail 284f69fb49e2e385203f52441b324b9a68461d6b c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
 97577 fail c5ad33184354260be6d05de57e46a5498692f6d6 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
 97582 pass c5bcec6cbcbf520f088dc7939934bbf10c20c5a5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
 97587 fail c5ad33184354260be6d05de57e46a5498692f6d6 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
 97591 pass c5bcec6cbcbf520f088dc7939934bbf10c20c5a5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
 97597 fail c5ad33184354260be6d05de57e46a5498692f6d6 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
Searching for interesting versions
 Result found: flight 96211 (pass), for basis pass
 Result found: flight 97496 (fail), for basis failure
 Repro found: flight 97497 (pass), for basis pass
 Repro found: flight 97556 (fail), for basis failure
 0 revisions at c5bcec6cbcbf520f088dc7939934bbf10c20c5a5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
No revisions left to test, checking graph state.
 Result found: flight 97566 (pass), for last pass
 Result found: flight 97577 (fail), for first failure
 Repro found: flight 97582 (pass), for last pass
 Repro found: flight 97587 (fail), for first failure
 Repro found: flight 97591 (pass), for last pass
 Repro found: flight 97597 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
  Bug introduced:  c5ad33184354260be6d05de57e46a5498692f6d6
  Bug not present: c5bcec6cbcbf520f088dc7939934bbf10c20c5a5
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/97597/


  commit c5ad33184354260be6d05de57e46a5498692f6d6
  Author: Lukasz Odzioba <lukasz.odzioba@intel.com>
  Date:   Fri Jun 24 14:50:01 2016 -0700
  
      mm/swap.c: flush lru pvecs on compound page arrival
      
      [ Upstream commit 8f182270dfec432e93fae14f9208a6b9af01009f ]
      
      Currently we can have compound pages held on per cpu pagevecs, which
      leads to a lot of memory unavailable for reclaim when needed.  In the
      systems with hundreads of processors it can be GBs of memory.
      
      On of the way of reproducing the problem is to not call munmap
      explicitly on all mapped regions (i.e.  after receiving SIGTERM).  After
      that some pages (with THP enabled also huge pages) may end up on
      lru_add_pvec, example below.
      
        void main() {
        #pragma omp parallel
        {
      	size_t size = 55 * 1000 * 1000; // smaller than  MEM/CPUS
      	void *p = mmap(NULL, size, PROT_READ | PROT_WRITE,
      		MAP_PRIVATE | MAP_ANONYMOUS , -1, 0);
      	if (p != MAP_FAILED)
      		memset(p, 0, size);
      	//munmap(p, size); // uncomment to make the problem go away
        }
        }
      
      When we run it with THP enabled it will leave significant amount of
      memory on lru_add_pvec.  This memory will be not reclaimed if we hit
      OOM, so when we run above program in a loop:
      
      	for i in `seq 100`; do ./a.out; done
      
      many processes (95% in my case) will be killed by OOM.
      
      The primary point of the LRU add cache is to save the zone lru_lock
      contention with a hope that more pages will belong to the same zone and
      so their addition can be batched.  The huge page is already a form of
      batched addition (it will add 512 worth of memory in one go) so skipping
      the batching seems like a safer option when compared to a potential
      excess in the caching which can be quite large and much harder to fix
      because lru_add_drain_all is way to expensive and it is not really clear
      what would be a good moment to call it.
      
      Similarly we can reproduce the problem on lru_deactivate_pvec by adding:
      madvise(p, size, MADV_FREE); after memset.
      
      This patch flushes lru pvecs on compound page arrival making the problem
      less severe - after applying it kill rate of above example drops to 0%,
      due to reducing maximum amount of memory held on pvec from 28MB (with
      THP) to 56kB per CPU.
      
      Suggested-by: Michal Hocko <mhocko@suse.com>
      Link: http://lkml.kernel.org/r/1466180198-18854-1-git-send-email-lukasz.odzioba@intel.com
      Signed-off-by: Lukasz Odzioba <lukasz.odzioba@intel.com>
      Acked-by: Michal Hocko <mhocko@suse.com>
      Cc: Kirill Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Vladimir Davydov <vdavydov@parallels.com>
      Cc: Ming Li <mingli199x@qq.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

pnmtopng: 73 colors found
Revision graph left in /home/logs/results/bisect/linux-4.1/test-amd64-i386-qemut-rhel6hvm-amd.redhat-install.{dot,ps,png,html,svg}.
----------------------------------------
97597: tolerable ALL FAIL

flight 97597 linux-4.1 real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/97597/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd  9 redhat-install    fail baseline untested


jobs:
 test-amd64-i386-qemut-rhel6hvm-amd                           fail    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

----- End forwarded message -----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

RE: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-admin@xenproject.org: [Xen-devel] [linux-4.1 bisection] complete test-amd64-i386-qemut-rhel6hvm-amd]

[Odzioba, Lukasz]

On Monday, July 18, 2016 5:31 PM, Konrad Rzeszutek Wilk wrote:
> We found that your patch in the automated Xen test-case ends up
> OOMing the box when trying to install guests. This worked prior
> to your patch.
>
> See serial log:
> http://logs.test-lab.xenproject.org/osstest/logs/97597/test-amd64-i386-qemut-rhel6hvm-amd/serial-pinot0.log
>
> Would it be OK to revert this patch from the stable trees?

I think it is ok to revert that, but the source of a problem may be somewhere else.
Is it the only problem with this patch, you see?
By stable trees do you mean just 4.1 or all stable trees?

Thanks,
Lukas

Re: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-admin@xenproject.org: [linux-4.1 bisection] complete test-amd64-i386-qemut-rhel6hvm-amd]

[Konrad Rzeszutek Wilk]

On Mon, Jul 18, 2016 at 03:48:03PM +0000, Odzioba, Lukasz wrote:
> On Monday, July 18, 2016 5:31 PM, Konrad Rzeszutek Wilk wrote:
> > We found that your patch in the automated Xen test-case ends up
> > OOMing the box when trying to install guests. This worked prior
> > to your patch.
> >
> > See serial log:
> > http://logs.test-lab.xenproject.org/osstest/logs/97597/test-amd64-i386-qemut-rhel6hvm-amd/serial-pinot0.log
> >
> > Would it be OK to revert this patch from the stable trees?
> 
> I think it is ok to revert that, but the source of a problem may be somewhere else.
> Is it the only problem with this patch, you see?

I believe so.

> By stable trees do you mean just 4.1 or all stable trees?

We have only tested 3.18 and 4.1. It may be that other stable trees
are affected.
> 
> Thanks,
> Lukas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-admin@xenproject.org: [Xen-devel] [linux-4.1 bisection] complete test-amd64-i386-qemut-rhel6hvm-amd]

[Sebastian Gottschall]

i have the same issue without xen. for me network traffic causes oom 
within seconds to 3 minutes on embedded systems.
but i dont know if this is the cause. i just can say that it was 
introduced with 3.18.37


  Am 18.07.2016 um 18:18 schrieb Konrad Rzeszutek Wilk:
> On Mon, Jul 18, 2016 at 03:48:03PM +0000, Odzioba, Lukasz wrote:
>> On Monday, July 18, 2016 5:31 PM, Konrad Rzeszutek Wilk wrote:
>>> We found that your patch in the automated Xen test-case ends up
>>> OOMing the box when trying to install guests. This worked prior
>>> to your patch.
>>>
>>> See serial log:
>>> http://logs.test-lab.xenproject.org/osstest/logs/97597/test-amd64-i386-qemut-rhel6hvm-amd/serial-pinot0.log
>>>
>>> Would it be OK to revert this patch from the stable trees?
>> I think it is ok to revert that, but the source of a problem may be somewhere else.
>> Is it the only problem with this patch, you see?
> I believe so.
>
>> By stable trees do you mean just 4.1 or all stable trees?
> We have only tested 3.18 and 4.1. It may be that other stable trees
> are affected.
>> Thanks,
>> Lukas
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Is: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-admin@xenproject.org: [Xen-devel] [linux-4.1 bisection] complete test-amd64-i386-qemut-rhel6hvm-amd]

[Michal Hocko]

[CCing Sasha]

On Mon 18-07-16 11:30:46, Konrad Rzeszutek Wilk wrote:
> Hey Lukasz,
> 
> We found that your patch in the automated Xen test-case ends up
> OOMing the box when trying to install guests. This worked prior
> to your patch.
> 
> See serial log:
> http://logs.test-lab.xenproject.org/osstest/logs/97597/test-amd64-i386-qemut-rhel6hvm-amd/serial-pinot0.log
> 
> Would it be OK to revert this patch from the stable trees?

The fix up is trivial so I believe it would be better to apply the
follow up fix
http://lkml.kernel.org/r/20160714175521.3675e3d6@gandalf.local.home
-- 
Michal Hocko
SUSE Labs

Re: Is: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-admin@xenproject.org: [linux-4.1 bisection] complete test-amd64-i386-qemut-rhel6hvm-amd]

[Sebastian Gottschall]

[-- Attachment #1.1: Type: text/plain, Size: 1018 bytes --]

No such Message-ID known.



Am 19.07.2016 um 10:32 schrieb Michal Hocko:
> [CCing Sasha]
>
> On Mon 18-07-16 11:30:46, Konrad Rzeszutek Wilk wrote:
>> Hey Lukasz,
>>
>> We found that your patch in the automated Xen test-case ends up
>> OOMing the box when trying to install guests. This worked prior
>> to your patch.
>>
>> See serial log:
>> http://logs.test-lab.xenproject.org/osstest/logs/97597/test-amd64-i386-qemut-rhel6hvm-amd/serial-pinot0.log
>>
>> Would it be OK to revert this patch from the stable trees?
> The fix up is trivial so I believe it would be better to apply the
> follow up fix
> http://lkml.kernel.org/r/20160714175521.3675e3d6@gandalf.local.home


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


[-- Attachment #1.2: Type: text/html, Size: 2294 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Is: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-admin@xenproject.org: [Xen-devel] [linux-4.1 bisection] complete test-amd64-i386-qemut-rhel6hvm-amd]

[Michal Hocko]

On Tue 19-07-16 10:35:09, Sebastian Gottschall wrote:
> No such Message-ID known.

Ups, sorry about that. I didn't know that the stable tree is not
archived via lkml.kernel.org. Here is the link
http://www.spinics.net/lists/stable/msg138760.html
 
> Am 19.07.2016 um 10:32 schrieb Michal Hocko:
> > [CCing Sasha]
> > 
> > On Mon 18-07-16 11:30:46, Konrad Rzeszutek Wilk wrote:
> > > Hey Lukasz,
> > > 
> > > We found that your patch in the automated Xen test-case ends up
> > > OOMing the box when trying to install guests. This worked prior
> > > to your patch.
> > > 
> > > See serial log:
> > > http://logs.test-lab.xenproject.org/osstest/logs/97597/test-amd64-i386-qemut-rhel6hvm-amd/serial-pinot0.log
> > > 
> > > Would it be OK to revert this patch from the stable trees?
> > The fix up is trivial so I believe it would be better to apply the
> > follow up fix
> > http://lkml.kernel.org/r/20160714175521.3675e3d6@gandalf.local.home
-- 
Michal Hocko
SUSE Labs

Re: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-admin@xenproject.org: [Xen-devel] [linux-4.1 bisection] complete test-amd64-i386-qemut-rhel6hvm-amd]

[Ian Jackson]

I see that linux-4.1.y is still at 5880876e9469 which has the serious
bug introduced by the backport c5ad33184354 "mm/swap.c: flush lru
pvecs on compound page arrival".

The analogous problem is also still affecting at least linux-3.18.y.

Is there some problem with reverting this patch in the stable
branches ?

Thanks,
Ian.

Re: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-admin@xenproject.org: [Xen-devel] [linux-4.1 bisection] complete test-amd64-i386-qemut-rhel6hvm-amd]

[Michal Hocko]

On Thu 21-07-16 13:45:40, Ian Jackson wrote:
> I see that linux-4.1.y is still at 5880876e9469 which has the serious
> bug introduced by the backport c5ad33184354 "mm/swap.c: flush lru
> pvecs on compound page arrival".
> 
> The analogous problem is also still affecting at least linux-3.18.y.
> 
> Is there some problem with reverting this patch in the stable
> branches ?

Sasha has mentioned he queued up the follow up fix. I am not sure who is
the 3.18 maintainer but he should do the same.

I am slightly worried that Sasha's email is bouncing for several days
and I am not sure who is his backup. For the time being I would just
suggest doing a local revert or apply Steven's patch from
http://www.spinics.net/lists/stable/msg138760.html
-- 
Michal Hocko
SUSE Labs

Re: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-admin@xenproject.org: [Xen-devel] [linux-4.1 bisection] complete test-amd64-i386-qemut-rhel6hvm-amd]

[Sebastian Gottschall]

Am 21.07.2016 um 16:23 schrieb Michal Hocko:
> On Thu 21-07-16 13:45:40, Ian Jackson wrote:
>> I see that linux-4.1.y is still at 5880876e9469 which has the serious
>> bug introduced by the backport c5ad33184354 "mm/swap.c: flush lru
>> pvecs on compound page arrival".
>>
>> The analogous problem is also still affecting at least linux-3.18.y.
>>
>> Is there some problem with reverting this patch in the stable
>> branches ?
> Sasha has mentioned he queued up the follow up fix. I am not sure who is

> the 3.18 maintainer but he should do the same.
>
> I am slightly worried that Sasha's email is bouncing for several days
> and I am not sure who is his backup. For the time being I would just
> suggest doing a local revert or apply Steven's patch from
> http://www.spinics.net/lists/stable/msg138760.html
i patched it it locally and it resolved the issue in 3.18


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565