Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp5639073imm; Mon, 23 Jul 2018 03:28:06 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdzoOwiF6mCFGtg8F8ZQKC7bzimRDLidG9ak24ipGoawKiWHu+e/xoNMwHyPU2xRuW+pqod X-Received: by 2002:a63:d613:: with SMTP id q19-v6mr11625434pgg.327.1532341686174; Mon, 23 Jul 2018 03:28:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532341686; cv=none; d=google.com; s=arc-20160816; b=0A2urdxol3utafTHNfyhmTqmYbfkzB7EEmk1e5ffuPwRaDDgodHiUeI1s4CAA/RM6b ixgO9cJjCOHxKXVxxggwRNJ6Dic4kMKGTZiFhjEW1Msq3p2xU2lmXAonZ7FO2/F5ybhj lygdnfaPXE92TcVihQLnZMp/K4Jr3GdcyKH0/ZfzXhkmgDuE06Q8map5ySlL1z4tHcew XgZzJH1/Q2jdfjo4JOLMe6MwMQbrMD4izOuTvWgmTwuu4TkTB4vt/R6Xgizmb/gkH3mw PgLd0msdhCKdOeRsVbkmaqsTO9w4KeOzsBeNbxf+DShoz/+zVkcApibho5fL9WsfHPfk K1gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :references:subject:cc:to:mime-version:user-agent:from:date :message-id:arc-authentication-results; bh=8BYHXJ7xw4ly/xsECYtknjQEcYN7+gPyJQCJ11+VtV8=; b=uKcIn6+lVSFGSnjQ5b1EgFOuYlt3LScMH+DjMYNcnFSbE4d6IQrs7G+AQzRwwbVLeW yGJ2P12wkY1J/ED/Ysv5Ezg2p1yig7tUjlCfx4xHMxXpoQjpjzcaIRSqfzCxJuGHBwNZ XtzvGmFmO9MYSv655QiWP7rnL3oV8s77iQSXiQAHhq8+9cUNP+7mFutcSTMEPUJ8QZQ6 eljsqQ+IHoXDxSnWWWobkGw66+TfV6FX7aMsURJTwagtuUVka7j8w87w4edSNDE+8Q6o A/ux73Hb9vtQIaGhuzqIPr76UG9K/U1Ch3P/OorRZqAUQ0hVWcCK92YexuP6F0m5dYpF WjvQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g4-v6si7375129pgl.139.2018.07.23.03.27.51; Mon, 23 Jul 2018 03:28:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388203AbeGWL1G (ORCPT + 99 others); Mon, 23 Jul 2018 07:27:06 -0400 Received: from mga06.intel.com ([134.134.136.31]:62236 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388021AbeGWL1F (ORCPT ); Mon, 23 Jul 2018 07:27:05 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2018 03:26:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,393,1526367600"; d="scan'208";a="74686894" Received: from unknown (HELO [10.239.13.97]) ([10.239.13.97]) by fmsmga001.fm.intel.com with ESMTP; 23 Jul 2018 03:26:29 -0700 Message-ID: <5B55AE56.5030404@intel.com> Date: Mon, 23 Jul 2018 18:30:46 +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" CC: virtio-dev@lists.oasis-open.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org, akpm@linux-foundation.org, torvalds@linux-foundation.org, pbonzini@redhat.com, liliang.opensource@gmail.com, yang.zhang.wz@gmail.com, quan.xu0@gmail.com, nilal@redhat.com, riel@redhat.com, peterx@redhat.com Subject: Re: [PATCH v36 2/5] virtio_balloon: replace oom notifier with shrinker References: <1532075585-39067-1-git-send-email-wei.w.wang@intel.com> <1532075585-39067-3-git-send-email-wei.w.wang@intel.com> <20180722174125-mutt-send-email-mst@kernel.org> In-Reply-To: <20180722174125-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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/22/2018 10:48 PM, Michael S. Tsirkin wrote: > On Fri, Jul 20, 2018 at 04:33:02PM +0800, Wei Wang wrote: >> >> +static unsigned long virtio_balloon_shrinker_scan(struct shrinker *shrinker, >> + struct shrink_control *sc) >> +{ >> + unsigned long pages_to_free = balloon_pages_to_shrink, >> + pages_freed = 0; >> + struct virtio_balloon *vb = container_of(shrinker, >> + struct virtio_balloon, shrinker); >> + >> + /* >> + * One invocation of leak_balloon can deflate at most >> + * VIRTIO_BALLOON_ARRAY_PFNS_MAX balloon pages, so we call it >> + * multiple times to deflate pages till reaching >> + * balloon_pages_to_shrink pages. >> + */ >> + while (vb->num_pages && pages_to_free) { >> + pages_to_free = balloon_pages_to_shrink - pages_freed; >> + pages_freed += leak_balloon(vb, pages_to_free); >> + } >> + update_balloon_size(vb); > Are you sure that this is never called if count returned 0? Yes. Please see do_shrink_slab, it just returns if count is 0. > >> + >> + return pages_freed / VIRTIO_BALLOON_PAGES_PER_PAGE; >> +} >> + >> +static unsigned long virtio_balloon_shrinker_count(struct shrinker *shrinker, >> + struct shrink_control *sc) >> +{ >> + struct virtio_balloon *vb = container_of(shrinker, >> + struct virtio_balloon, shrinker); >> + >> + /* >> + * We continue to use VIRTIO_BALLOON_F_DEFLATE_ON_OOM to handle the >> + * case when shrinker needs to be invoked to relieve memory pressure. >> + */ >> + if (!virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM)) >> + return 0; > So why not skip notifier registration when deflate on oom > is clear? Sounds good, thanks. > vb->vb_dev_info.inode->i_mapping->a_ops = &balloon_aops; > #endif > + err = virtio_balloon_register_shrinker(vb); > + if (err) > + goto out_del_vqs; > > So we can get scans before device is ready. Leak will fail > then. Why not register later after device is ready? Probably no. - it would be better not to set device ready when register_shrinker failed. - When the device isn't ready, ballooning won't happen, that is, vb->num_pages will be 0, which results in shrinker_count=0 and shrinker_scan won't be called. So I think it would be better to have shrinker registered before device_ready. Best, Wei