similar to: [PATCH] virtio_balloon: set DRIVER_OK before using device

On Thu, Mar 05, 2015 at 01:24:47PM +1030, Rusty Russell wrote: > "Michael S. Tsirkin" <mst at redhat.com> writes: > > virtio spec requires that all drivers set DRIVER_OK > > before using devices. While balloon isn't yet > > included in the virtio 1 spec, previous spec versions > > also required this. > > > > virtio balloon might violate

On Thu, Mar 05, 2015 at 01:24:47PM +1030, Rusty Russell wrote: > "Michael S. Tsirkin" <mst at redhat.com> writes: > > virtio spec requires that all drivers set DRIVER_OK > > before using devices. While balloon isn't yet > > included in the virtio 1 spec, previous spec versions > > also required this. > > > > virtio balloon might violate

"Michael S. Tsirkin" <mst at redhat.com> writes: > virtio spec requires that all drivers set DRIVER_OK > before using devices. While balloon isn't yet > included in the virtio 1 spec, previous spec versions > also required this. > > virtio balloon might violate this rule: probe calls > kthread_run before setting DRIVER_OK, which might run > immediately

"Michael S. Tsirkin" <mst at redhat.com> writes: > virtio spec requires that all drivers set DRIVER_OK > before using devices. While balloon isn't yet > included in the virtio 1 spec, previous spec versions > also required this. > > virtio balloon might violate this rule: probe calls > kthread_run before setting DRIVER_OK, which might run > immediately

It has been long since I have sent v3 of the balloon conversion from a kthread to a workqueue. I have gained some more experience with the APIs in the meantime. I hope that you would like the outcome. I have added one more patch that fixes a separate problem with restoring the balloon after the system freeze. I have found this when testing the conversion. Changes against v3: + rebased on

It has been long since I have sent v3 of the balloon conversion from a kthread to a workqueue. I have gained some more experience with the APIs in the meantime. I hope that you would like the outcome. I have added one more patch that fixes a separate problem with restoring the balloon after the system freeze. I have found this when testing the conversion. Changes against v3: + rebased on

The previous version did not prevent updating the balloon when it was being removed. There was an idea to update the stats in a separate work and cancel it after the config reset. But this does not seem to work. The code for updating the stats communicates with the host. IMHO, it should not run after the reset (flushing buffers). Therefore I decided to use a boolean value and a spin lock (inspired

The previous version did not prevent updating the balloon when it was being removed. There was an idea to update the stats in a separate work and cancel it after the config reset. But this does not seem to work. The code for updating the stats communicates with the host. IMHO, it should not run after the reset (flushing buffers). Therefore I decided to use a boolean value and a spin lock (inspired

On Fri, Dec 04, 2015 at 02:37:51PM +0100, Petr Mladek wrote: > From: Petr Mladek <pmladek at suse.cz> > > This patch moves the deferred work from the "vballoon" kthread into a > system freezable workqueue. > > We do not need to maintain and run a dedicated kthread. Also the event > driven workqueues API makes the logic much easier. Especially, we do > not

On Fri, Dec 04, 2015 at 02:37:51PM +0100, Petr Mladek wrote: > From: Petr Mladek <pmladek at suse.cz> > > This patch moves the deferred work from the "vballoon" kthread into a > system freezable workqueue. > > We do not need to maintain and run a dedicated kthread. Also the event > driven workqueues API makes the logic much easier. Especially, we do > not

From: Petr Mladek <pmladek at suse.cz> This patch moves the deferred work from the "vballoon" kthread into a system freezable workqueue. We do not need to maintain and run a dedicated kthread. Also the event driven workqueues API makes the logic much easier. Especially, we do not longer need an own wait queue, wait function, and freeze point. The conversion is pretty

virtio spec requires that all drivers set DRIVER_OK before using devices. While rpmsg isn't yet included in the virtio 1 spec, previous spec versions also required this. virtio rpmsg violates this rule: is calls kick before setting DRIVER_OK. The fix isn't trivial since simply calling virtio_device_ready earlier would mean we might get an interrupt in parallel with adding buffers.

virtio spec requires that all drivers set DRIVER_OK before using devices. While rpmsg isn't yet included in the virtio 1 spec, previous spec versions also required this. virtio rpmsg violates this rule: is calls kick before setting DRIVER_OK. The fix isn't trivial since simply calling virtio_device_ready earlier would mean we might get an interrupt in parallel with adding buffers.

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

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 runs out of memory and invokes OOM-killer. The balancing of

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 runs out of memory and invokes OOM-killer. The balancing of

On Mon, Mar 9, 2015 at 10:41 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Sat, Mar 07, 2015 at 08:06:56PM +0100, Michael S. Tsirkin wrote: >> virtio spec requires that all drivers set DRIVER_OK >> before using devices. While rpmsg isn't yet >> included in the virtio 1 spec, previous spec versions >> also required this. >> >> virtio rpmsg

On Mon, Mar 9, 2015 at 10:41 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Sat, Mar 07, 2015 at 08:06:56PM +0100, Michael S. Tsirkin wrote: >> virtio spec requires that all drivers set DRIVER_OK >> before using devices. While rpmsg isn't yet >> included in the virtio 1 spec, previous spec versions >> also required this. >> >> virtio rpmsg

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 runs out of memory and invokes OOM-killer. The balancing of