From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751956AbdJSH5z (ORCPT ); Thu, 19 Oct 2017 03:57:55 -0400 Received: from mga03.intel.com ([134.134.136.65]:14207 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751922AbdJSH5v (ORCPT ); Thu, 19 Oct 2017 03:57:51 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,400,1503385200"; d="scan'208";a="139945473" Message-ID: <59E85B7A.1090800@intel.com> Date: Thu, 19 Oct 2017 15:59:54 +0800 From: Wei Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael S. Tsirkin" , Tetsuo Handa CC: linux-kernel@vger.kernel.org, mhocko@suse.com, jasowang@redhat.com, virtualization@lists.linux-foundation.org, linux-mm@kvack.org Subject: Re: [PATCH] virtio_balloon: fix deadlock on OOM References: <1507900754-32239-1-git-send-email-mst@redhat.com> <201710132306.FBC78628.OJLHFVQSFOtOMF@I-love.SAKURA.ne.jp> <20171018201700-mutt-send-email-mst@kernel.org> In-Reply-To: <20171018201700-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/19/2017 01:19 AM, Michael S. Tsirkin wrote: > On Fri, Oct 13, 2017 at 11:06:23PM +0900, Tetsuo Handa wrote: >> Michael S. Tsirkin wrote: >>> This is a replacement for >>> [PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify() >>> but unlike that patch it actually deflates on oom even in presence of >>> lock contention. >> But Wei Wang is proposing VIRTIO_BALLOON_F_SG which will try to allocate >> memory, isn't he? > Hopefully that can be fixed by allocating outside the lock. > I think that would still have an issue even without the lock, because we can't do any memory allocation in the OOM code path. Probably, we could write a separate function, leak_balloon_oom() for the oom notifier, which puts the oom deflating pages to the vq one by one, and kick when the vq is full. In this case, we would need to stop the normal leak_balloon while oom deflating starts. However, a better optimization I think would be to do some kind of consolidation, since leak_balloon is already deflating, leak_ballon_oom can just count the number of pages that have been deflated by leak_balloon and return when it reaches oom_pages. Best, Wei