search for: oom_notify

...> > Michael S. Tsirkin wrote: > > > On Mon, Sep 11, 2017 at 07:27:19PM +0900, Tetsuo Handa wrote: > > > > Hello. > > > > > > > > I noticed that virtio_balloon is using register_oom_notifier() and > > > > leak_balloon() from virtballoon_oom_notify() might depend on > > > > __GFP_DIRECT_RECLAIM memory allocation. > > > > > > > > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to > > > > serialize against fill_balloon(). But in fill_balloon(), > > > > alloc...

Hello. I noticed that virtio_balloon is using register_oom_notifier() and leak_balloon() from virtballoon_oom_notify() might depend on __GFP_DIRECT_RECLAIM memory allocation. In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize against fill_balloon(). But in fill_balloon(), alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is called with vb->balloon_lock...

Hello. I noticed that virtio_balloon is using register_oom_notifier() and leak_balloon() from virtballoon_oom_notify() might depend on __GFP_DIRECT_RECLAIM memory allocation. In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize against fill_balloon(). But in fill_balloon(), alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is called with vb->balloon_lock...

...ing here (also discussed in the deadlock patch before): Suppose we use a sleep-able flag GFP_KERNEL, which gets the caller (fill_balloon or leak_balloon) into sleep with balloon_lock being held, and the memory reclaiming from GFP_KERNEL would fall into the OOM code path which first invokes the oom_notify-->leak_balloon to release some balloon memory, which needs to take the balloon_lock that is being held by the task who is sleeping. So, using GFP_NOWAIT avoids sleeping to get memory through directly memory reclaiming, which could fall into that OOM code path that needs to take the balloon_l...

...truct virtio_balloon and its queue operations (please see commit > e22504296d). This prevents the concurrent run of the leak_balloon and > fill_balloon functions, thereby resulting in a deadlock issue on OOM: > > fill_balloon: take balloon_lock and wait for OOM to get some memory; > oom_notify: release some inflated memory via leak_balloon(); > leak_balloon: wait for balloon_lock to be released by fill_balloon. > > This patch breaks the lock into two fine-grained inflate_lock and > deflate_lock, and eliminates the unnecessary use of the shared data > (i.e. vb->pnfs, vb...

...truct virtio_balloon and its queue operations (please see commit > e22504296d). This prevents the concurrent run of the leak_balloon and > fill_balloon functions, thereby resulting in a deadlock issue on OOM: > > fill_balloon: take balloon_lock and wait for OOM to get some memory; > oom_notify: release some inflated memory via leak_balloon(); > leak_balloon: wait for balloon_lock to be released by fill_balloon. > > This patch breaks the lock into two fine-grained inflate_lock and > deflate_lock, and eliminates the unnecessary use of the shared data > (i.e. vb->pnfs, vb...

...o-balloon: deflate up to oom_pages on OOM by Wei Wang to try to fix it: https://lore.kernel.org/r/1508500466-21165-3-git-send-email-wei.w.wang at intel.com but this was dropped. > Also, pay attention that leak_balloon() returns the number of 4k pages - > convert it properly in virtio_balloon_oom_notify(). Oh. So it was returning a wrong value originally (before 71994620bb25). However what really matters for notifiers is whether the value is 0 - whether we made progress. So it's cosmetic. > Note1: using the OOM handler is frowned upon, but it really is what we > need for this fe...

...o-balloon: deflate up to oom_pages on OOM by Wei Wang to try to fix it: https://lore.kernel.org/r/1508500466-21165-3-git-send-email-wei.w.wang at intel.com but this was dropped. > Also, pay attention that leak_balloon() returns the number of 4k pages - > convert it properly in virtio_balloon_oom_notify(). Oh. So it was returning a wrong value originally (before 71994620bb25). However what really matters for notifiers is whether the value is 0 - whether we made progress. So it's cosmetic. > Note1: using the OOM handler is frowned upon, but it really is what we > need for this fe...

...n and its queue operations (please see commit >> e22504296d). This prevents the concurrent run of the leak_balloon and >> fill_balloon functions, thereby resulting in a deadlock issue on OOM: >> >> fill_balloon: take balloon_lock and wait for OOM to get some memory; >> oom_notify: release some inflated memory via leak_balloon(); >> leak_balloon: wait for balloon_lock to be released by fill_balloon. >> >> This patch breaks the lock into two fine-grained inflate_lock and >> deflate_lock, and eliminates the unnecessary use of the shared data >> (i...

...x it: > https://lore.kernel.org/r/1508500466-21165-3-git-send-email-wei.w.wang at intel.com > but this was dropped. Makes sense. 1MB is usually good enough. > >> Also, pay attention that leak_balloon() returns the number of 4k pages - >> convert it properly in virtio_balloon_oom_notify(). > > Oh. So it was returning a wrong value originally (before 71994620bb25). > However what really matters for notifiers is whether the value is 0 - > whether we made progress. So it's cosmetic. Yes, that's also my understanding. > >> Note1: using the OOM handler...

...s demand to elements of struct virtio_balloon and its queue operations (please see commit e22504296d). This prevents the concurrent run of the leak_balloon and fill_balloon functions, thereby resulting in a deadlock issue on OOM: fill_balloon: take balloon_lock and wait for OOM to get some memory; oom_notify: release some inflated memory via leak_balloon(); leak_balloon: wait for balloon_lock to be released by fill_balloon. This patch breaks the lock into two fine-grained inflate_lock and deflate_lock, and eliminates the unnecessary use of the shared data (i.e. vb->pnfs, vb->num_pfns). This enab...

On Tue, Dec 12, 2017 at 07:55:55PM +0800, Wei Wang wrote: > +int xb_preload_and_set_bit(struct xb *xb, unsigned long bit, gfp_t gfp); I'm struggling to understand when one would use this. The xb_ API requires you to handle your own locking. But specifying GFP flags here implies you can sleep. So ... um ... there's no locking? > +void xb_clear_bit_range(struct xb *xb, unsigned

On Tue, Dec 12, 2017 at 07:55:55PM +0800, Wei Wang wrote: > +int xb_preload_and_set_bit(struct xb *xb, unsigned long bit, gfp_t gfp); I'm struggling to understand when one would use this. The xb_ API requires you to handle your own locking. But specifying GFP flags here implies you can sleep. So ... um ... there's no locking? > +void xb_clear_bit_range(struct xb *xb, unsigned

...r/1508500466-21165-3-git-send-email-wei.w.wang at intel.com > > but this was dropped. > > Makes sense. 1MB is usually good enough. > > > > >> Also, pay attention that leak_balloon() returns the number of 4k pages - > >> convert it properly in virtio_balloon_oom_notify(). > > > > Oh. So it was returning a wrong value originally (before 71994620bb25). > > However what really matters for notifiers is whether the value is 0 - > > whether we made progress. So it's cosmetic. > > Yes, that's also my understanding. > > >...

...r/1508500466-21165-3-git-send-email-wei.w.wang at intel.com > > but this was dropped. > > Makes sense. 1MB is usually good enough. > > > > >> Also, pay attention that leak_balloon() returns the number of 4k pages - > >> convert it properly in virtio_balloon_oom_notify(). > > > > Oh. So it was returning a wrong value originally (before 71994620bb25). > > However what really matters for notifiers is whether the value is 0 - > > whether we made progress. So it's cosmetic. > > Yes, that's also my understanding. > > >...

This patch series intends to summarize the recent contributions made by Michael S. Tsirkin, Tetsuo Handa, Michal Hocko etc. via reporting and discussing the related deadlock issues on the mailinglist. Please check each patch for details. >From a high-level point of view, this patch series achieves: 1) eliminate the deadlock issue fundamentally caused by the inability to run leak_balloon and

This patch series intends to summarize the recent contributions made by Michael S. Tsirkin, Tetsuo Handa, Michal Hocko etc. via reporting and discussing the related deadlock issues on the mailinglist. Please check each patch for details. >From a high-level point of view, this patch series achieves: 1) eliminate the deadlock issue fundamentally caused by the inability to run leak_balloon and

> -----Original Message----- > From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org] > On Behalf Of Yijing Wang > Sent: Saturday, July 26, 2014 8:39 AM > To: linux-kernel at vger.kernel.org > Cc: Xinwei Hu; Wuyun; Bjorn Helgaas; linux-pci at vger.kernel.org; > Paul.Mundt at huawei.com; James E.J. Bottomley; Marc Zyngier; linux-arm- > kernel at

> -----Original Message----- > From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org] > On Behalf Of Yijing Wang > Sent: Saturday, July 26, 2014 8:39 AM > To: linux-kernel at vger.kernel.org > Cc: Xinwei Hu; Wuyun; Bjorn Helgaas; linux-pci at vger.kernel.org; > Paul.Mundt at huawei.com; James E.J. Bottomley; Marc Zyngier; linux-arm- > kernel at

Pci_dev_msi_enabled() is used to check whether device MSI/MSIX enabled. Refactor this function to suuport checking only device MSI or MSIX enabled. Signed-off-by: Yijing Wang <wangyijing at huawei.com> --- arch/cris/arch-v32/drivers/pci/bios.c | 2 +- arch/frv/mb93090-mb00/pci-vdk.c | 2 +- arch/ia64/pci/pci.c | 4 ++--