similar to: No subject

Hi - Running into the error below when copying over large files via ssh. This occurs even when I have vm.overcommit_memory=2 set in /etc/sysctl.conf. The research I've done indicates that this is a bio-uses-GFP_DMA bug with EM64T. I'm running CentOS 4.4 with the 2.6.9-42.0.3.ELsmp x86_64 kernel on the following hardware: 2 x Intel Xeon CPU 5148 @ 2.33GHz Supermicro X7DB8 motherboard

Hello, In general I am in the habit of turning off memory overcommit because I believe it's a bad thing in a multi-user environment. This was never a problem on rhel5 systems, but on rhel6, I am having issues. When I try to set overcommit_memory=2, my system locks up. It basically behaves as if the memory is all used up... I see the same behavior on centos6 or rhel6. Following is

On Wed, Oct 18, 2017 at 07:59:23PM +0900, Tetsuo Handa wrote: > Tetsuo Handa wrote: > > 20171016-deflate.log.xz continued printing "puff" messages without any OOM > > killer messages, for fill_balloon() always inflates faster than leak_balloon() > > deflates. > > > > Since the OOM killer cannot be invoked unless leak_balloon() completely > >

Hi All, I have a server that has its swappiness set to 0. It is running a little tight on memory and so there have been a couple of events where the OOM_killer has been invoked and killed off MySQL, which you would expect. Now if you have your swappiness at 0 then "A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high

On Mar 10, 2017, at 3:51 PM, Wensheng Deng <wd35 at nyu.edu> wrote: > > I have 3.10 kernel. I am running some data processing job, need to first > copy big (>5 GB) input files. The jobs were killed, because the system > thought I used 5 GB memory from the file copying. If you?re using ?cp? you probably aren?t using 5G of RAM. That?s not how ?cp? works. Actual errors might

Tetsuo Handa wrote: > 20171016-deflate.log.xz continued printing "puff" messages without any OOM > killer messages, for fill_balloon() always inflates faster than leak_balloon() > deflates. > > Since the OOM killer cannot be invoked unless leak_balloon() completely > deflates faster than fill_balloon() inflates, the guest remained unusable > (e.g. unable to login

Tetsuo Handa wrote: > 20171016-deflate.log.xz continued printing "puff" messages without any OOM > killer messages, for fill_balloon() always inflates faster than leak_balloon() > deflates. > > Since the OOM killer cannot be invoked unless leak_balloon() completely > deflates faster than fill_balloon() inflates, the guest remained unusable > (e.g. unable to login

Is there any articles that explain in detail how actually guestmount works internally? My main question is how does guestfs deal with backing disk changes. So, I have a libvirt/qemu-kvm setup. Each vm has a lvm2 volume for a disk. For example, I want to mount one of these volumes and read some data. 1. I mount the volume using guestmount (guestmount --ro -d <libvirt domain> -m /dev/sda1

I have continous oom&panic situation unresolved. I am not sure system fills up all the ram (36GB). Why this system triggered this oom situation? Is it about some other memory? highmem? lowmem? stack size? Best Regards, Kernel 3.10.24 Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0 Dec 27 09:19:05 2013 kernel: :

Tetsuo Handa wrote: > Michael S. Tsirkin wrote: > > > > > > > > The proper fix isn't that hard - just avoid allocations under lock. > > > > > > > > Patch posted, pls take a look. > > > > > > Your patch allocates pages in order to inflate the balloon, but > > > your patch will allow leak_balloon() to deflate the

Tetsuo Handa wrote: > Michael S. Tsirkin wrote: > > > > > > > > The proper fix isn't that hard - just avoid allocations under lock. > > > > > > > > Patch posted, pls take a look. > > > > > > Your patch allocates pages in order to inflate the balloon, but > > > your patch will allow leak_balloon() to deflate the

From: Raushaniya Maksudova <rmaksudova at parallels.com> Excessive virtio_balloon inflation can cause invocation of OOM-killer, when Linux is under severe memory pressure. Various mechanisms are responsible for correct virtio_balloon memory management. Nevertheless it is often the case that these control tools does not have enough time to react on fast changing memory load. As a result OS

From: Raushaniya Maksudova <rmaksudova at parallels.com> Excessive virtio_balloon inflation can cause invocation of OOM-killer, when Linux is under severe memory pressure. Various mechanisms are responsible for correct virtio_balloon memory management. Nevertheless it is often the case that these control tools does not have enough time to react on fast changing memory load. As a result OS

From: Raushaniya Maksudova <rmaksudova at parallels.com> Excessive virtio_balloon inflation can cause invocation of OOM-killer, when Linux is under severe memory pressure. Various mechanisms are responsible for correct virtio_balloon memory management. Nevertheless it is often the case that these control tools does not have enough time to react on fast changing memory load. As a result OS

From: Raushaniya Maksudova <rmaksudova at parallels.com> Excessive virtio_balloon inflation can cause invocation of OOM-killer, when Linux is under severe memory pressure. Various mechanisms are responsible for correct virtio_balloon memory management. Nevertheless it is often the case that these control tools does not have enough time to react on fast changing memory load. As a result OS

Hi all, Please find below a complete transcript of the emails between debian/kernel-mm mailing lists. I've had a response back from someone on the deb mailing list stating: ==================================== The bug seems to be that sshd does not reset the OOM adjustment before running the login shell (or other program). Therefore, please report a bug against openssh-server.

On Thu, Sep 17, 2020 at 09:06:51AM +0000, Sprencz, Pal Csongor (GE Healthcare) wrote: > In short we have a ScientificLinux7 base host OS system, on top of > that I would want to run a KVM/QEMU virtual machine. > The kvm version is used on the host OS is the following. > qemu-kvm-common-1.5.3-173.el7_8.1.x86_64 > libvirt-daemon-driver-qemu-4.5.0-23.el7_7.6.x86_64 >

On Mon, Oct 16, 2017 at 07:58:29PM +0900, Tetsuo Handa wrote: > Tetsuo Handa wrote: > > Michael S. Tsirkin wrote: > > > > > > > > > > The proper fix isn't that hard - just avoid allocations under lock. > > > > > > > > > > Patch posted, pls take a look. > > > > > > > > Your patch allocates pages in

Michael S. Tsirkin wrote: > > > > > > The proper fix isn't that hard - just avoid allocations under lock. > > > > > > Patch posted, pls take a look. > > > > Your patch allocates pages in order to inflate the balloon, but > > your patch will allow leak_balloon() to deflate the balloon. > > How deflating the balloon (i.e. calling

Under both XEN 3.0.4 (2.6.16.33) and XEN 3.1 (2.6.18), I can make the OOM killer appear in dom0 of my server by doing heavy I/O from within a VM. If I start 5 VMs on the same server, each VM doing constant I/O over its boot disk (read/write a 2GB file), after about 30 minutes the OOM killer appears in dom0 and starts killing processes. This was observed using 256MB in dom0. If I bump the memory in