Received: by 10.223.176.5 with SMTP id f5csp3131671wra; Thu, 1 Feb 2018 11:15:34 -0800 (PST) X-Google-Smtp-Source: AH8x227Og7ZS79dCi5UGzg+dEfOmfG7Ipe2/9uE7Glwrjuof5Vn3wW+lZiCuwnRSNUiGd05aY14I X-Received: by 10.98.26.143 with SMTP id a137mr38547747pfa.100.1517512534377; Thu, 01 Feb 2018 11:15:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517512534; cv=none; d=google.com; s=arc-20160816; b=YpVxj5V+xoqRSg+yrGdnTc9Du6aQH7zbDCqxSDP2+KNmaAh9gTyMlN+Ky5gamFSFkt 6A3/oi50x8ZiMJiwKxzs/6/CK9AKuQEafIlAO7nh4EWftSpeaaOuG4lkvHNh8eq/0M5H 8h9eTVUaRB9RvZ5Kn7dw4sH+jzOCCXv8xDhCPu7xs9Cn/myBLY3xiYX7bng8bU8hWGMX wajPYhssHrD6okAqC8QZLYV+jS1LNVHI/ZXjN5x+qSBNLgowgTXis9RcfddmcwA48SMg jAZDeb07WrZIj6PrsWlowu6qPT6TIJbGveBLvpLyGSZQAv9APKz0KUpJANnV1gQz/tOy C5EA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=0nQh1fCExmR63AzgFUlZWuPrVtWPWD402Oi4Wv+98nc=; b=Zoo04+E7/4F/0JTp9ZLLXkuItZTdRksi2GkIT51OdMBY1aj98i+qMWH/jAcbBno+C3 EAtBR3OpuIdCpRxuvsZ/c9wnD9nv64R4+CjhAx2oqJOVcNxGmmjEB/hswx+ZSBZyGxoR oaz7iKNvJwvo/uaeFW5C/oVrFLb4RO0yBDNByayKzFx2aST4cJc9w476tpPH+gsN6uwT QivsZSvaUnxV1dbMCY4cLYKbQPI4+ZmJld7/TCMpEp9cMuQflmmQ35zQ9S24OSoA4l0U Lm34uAVPo2qXtPAsUjFc2PmAGVX2T9qQJuNhKOpMV2bjBKZ6iQujmj617sx92FP0jFW7 N7RQ== 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q23si188300pff.403.2018.02.01.11.15.19; Thu, 01 Feb 2018 11:15:34 -0800 (PST) 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754665AbeBATOo (ORCPT + 99 others); Thu, 1 Feb 2018 14:14:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32940 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753126AbeBATOi (ORCPT ); Thu, 1 Feb 2018 14:14:38 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 72367295D; Thu, 1 Feb 2018 19:14:38 +0000 (UTC) Received: from redhat.com (ovpn-126-9.rdu2.redhat.com [10.10.126.9]) by smtp.corp.redhat.com (Postfix) with SMTP id 512ED79161; Thu, 1 Feb 2018 19:14:31 +0000 (UTC) Date: Thu, 1 Feb 2018 21:14:25 +0200 From: "Michael S. Tsirkin" To: Tetsuo Handa Cc: Wei Wang , 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, pbonzini@redhat.com, liliang.opensource@gmail.com, yang.zhang.wz@gmail.com, quan.xu0@gmail.com, nilal@redhat.com, riel@redhat.com Subject: Re: [PATCH v24 2/2] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT Message-ID: <20180201211114-mutt-send-email-mst@kernel.org> References: <1516790562-37889-1-git-send-email-wei.w.wang@intel.com> <1516790562-37889-3-git-send-email-wei.w.wang@intel.com> <20180124183349-mutt-send-email-mst@kernel.org> <5A694FB5.5090803@intel.com> <17068749-d2c7-61bb-4637-a1aee5a0d0fb@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17068749-d2c7-61bb-4637-a1aee5a0d0fb@I-love.SAKURA.ne.jp> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 01 Feb 2018 19:14:38 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 25, 2018 at 08:28:52PM +0900, Tetsuo Handa wrote: > On 2018/01/25 12:32, Wei Wang wrote: > > On 01/25/2018 01:15 AM, Michael S. Tsirkin wrote: > >> On Wed, Jan 24, 2018 at 06:42:42PM +0800, Wei Wang wrote: > >> + > >> +static void report_free_page_func(struct work_struct *work) > >> +{ > >> + struct virtio_balloon *vb; > >> + unsigned long flags; > >> + > >> + vb = container_of(work, struct virtio_balloon, report_free_page_work); > >> + > >> + /* Start by sending the obtained cmd id to the host with an outbuf */ > >> + send_cmd_id(vb, &vb->start_cmd_id); > >> + > >> + /* > >> + * Set start_cmd_id to VIRTIO_BALLOON_FREE_PAGE_REPORT_STOP_ID to > >> + * indicate a new request can be queued. > >> + */ > >> + spin_lock_irqsave(&vb->stop_update_lock, flags); > >> + vb->start_cmd_id = cpu_to_virtio32(vb->vdev, > >> + VIRTIO_BALLOON_FREE_PAGE_REPORT_STOP_ID); > >> + spin_unlock_irqrestore(&vb->stop_update_lock, flags); > >> + > >> + walk_free_mem_block(vb, 0, &virtio_balloon_send_free_pages); > >> Can you teach walk_free_mem_block to return the && of all > >> return calls, so caller knows whether it completed? > > > > There will be two cases that can cause walk_free_mem_block to return without completing: > > 1) host requests to stop in advance > > 2) vq->broken > > > > How about letting walk_free_mem_block simply return the value returned by its callback (i.e. virtio_balloon_send_free_pages)? > > > > For host requests to stop, it returns "1", and the above only bails out when walk_free_mem_block return a "< 0" value. > > I feel that virtio_balloon_send_free_pages is doing too heavy things. > > It can be called for many times with IRQ disabled. Number of times > it is called depends on amount of free pages (and fragmentation state). > Generally, more free pages, more calls. > > Then, why don't you allocate some pages for holding all pfn values > and then call walk_free_mem_block() only for storing pfn values > and then send pfn values without disabling IRQ? So going over it, at some level we are talking about optimizations here. I'll go over it one last time but at some level we might be able to make progress faster if we start by enabling the functionality in question. If there are no other issues, I'm inclined to merge. If nothing else, this will make it possible for people to experiment and report sources of overhead. -- MST