Received: by 10.223.176.46 with SMTP id f43csp2007288wra; Thu, 25 Jan 2018 03:31:03 -0800 (PST) X-Google-Smtp-Source: AH8x226KUNkHU/n4dj2jSMXhd/QlICE2lLGNKY0wokkF8OOKJqeGZosjjd8+EjYTrG/PzP5/dcMb X-Received: by 2002:a17:902:46:: with SMTP id 64-v6mr11177452pla.341.1516879863048; Thu, 25 Jan 2018 03:31:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516879863; cv=none; d=google.com; s=arc-20160816; b=hyhnZ+jzDT10kNXdYV6Iw+btUcRKljrpEgoJOCTC/HA2HHJdAEjUxCzAzvIW2RnR9L w4veIiX9SsV/ht4Vpb7+++I/YvQ3xXyFNzVYiS2RVq+X2dj3EV7la3o5SGMz8PoUMs+X zxMreYF18t2tE00DHQSHFzNExLt9Dt5hUjK7uyigqc88pKF8DsTnSOXbYc9Dk3xJ0rjy SAVXdhIjdDmDtt7tjzV789TgILyIQ+tZMA+2X0aqS4CtL1I5t9Ul76joCGzryZwGRsTZ zF4nDNhG+7CHrYiaRBQST5ZiYsotPB27Axoqk+tzFlBVzycZderouL+np6ebEabJWPRd dpPA== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=M+BZjss3aZsX8ar50veKCcZP3K/PASRmnAIzdV3rEsE=; b=DfBQ6I4jXdvXpU92ZjdiqGyrMtbXFtCZtmAfxwefgEcodqFs8RzIpxxVbnTQVW2KsM S5nW9SiOyzob7jNbZjt1aWi+D92Vn5cJDZHNB4SYyXPD3yL8Vm4qZScGNigfoeMOdVTi JwhLdA3cYp0dHi6Ex6JwgPp8SMcNi9ta/3moeK6IGjcuYWgzUIg7PmG4l1daxXQKrquY NnFmlfDjNYOR8LndEmsqzmhY5oSflJBJ4TxH9f/6YIQHuE0J2+t5zGn2uouvNkfXQ/fS xMkErW9fMcHFKiZ9Gmtoop5KiCh/WGpXQL744GCB3zuE0fuakt8hXJr7Oju3H0cWc0mo H+qw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s13-v6si1829768plq.779.2018.01.25.03.30.48; Thu, 25 Jan 2018 03:31:03 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751718AbeAYL3S (ORCPT + 99 others); Thu, 25 Jan 2018 06:29:18 -0500 Received: from www262.sakura.ne.jp ([202.181.97.72]:18958 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751677AbeAYL3R (ORCPT ); Thu, 25 Jan 2018 06:29:17 -0500 Received: from fsav402.sakura.ne.jp (fsav402.sakura.ne.jp [133.242.250.101]) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id w0PBSq9u032617; Thu, 25 Jan 2018 20:28:52 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav402.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav402.sakura.ne.jp); Thu, 25 Jan 2018 20:28:52 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav402.sakura.ne.jp) Received: from [192.168.1.8] (softbank126074156036.bbtec.net [126.74.156.36]) (authenticated bits=0) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id w0PBSq2Q032612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jan 2018 20:28:52 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Subject: Re: [PATCH v24 2/2] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT To: Wei Wang , "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, pbonzini@redhat.com, liliang.opensource@gmail.com, yang.zhang.wz@gmail.com, quan.xu0@gmail.com, nilal@redhat.com, riel@redhat.com 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> From: Tetsuo Handa Message-ID: <17068749-d2c7-61bb-4637-a1aee5a0d0fb@I-love.SAKURA.ne.jp> Date: Thu, 25 Jan 2018 20:28:52 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <5A694FB5.5090803@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?