From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04DAFC4320D for ; Tue, 24 Sep 2019 14:23:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B6F6D214DA for ; Tue, 24 Sep 2019 14:23:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B6F6D214DA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 463516B000D; Tue, 24 Sep 2019 10:23:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4138B6B000E; Tue, 24 Sep 2019 10:23:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32A5B6B0010; Tue, 24 Sep 2019 10:23:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0180.hostedemail.com [216.40.44.180]) by kanga.kvack.org (Postfix) with ESMTP id 132916B000D for ; Tue, 24 Sep 2019 10:23:46 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id B90CA181AC9B4 for ; Tue, 24 Sep 2019 14:23:45 +0000 (UTC) X-FDA: 75970032810.27.view82_3b119a89eb0a X-HE-Tag: view82_3b119a89eb0a X-Filterd-Recvd-Size: 2880 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Sep 2019 14:23:45 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 5AB60AC84; Tue, 24 Sep 2019 14:23:43 +0000 (UTC) Date: Tue, 24 Sep 2019 16:23:42 +0200 From: Michal Hocko To: Alexander Duyck Cc: virtio-dev@lists.oasis-open.org, kvm@vger.kernel.org, mst@redhat.com, david@redhat.com, dave.hansen@intel.com, linux-kernel@vger.kernel.org, willy@infradead.org, linux-mm@kvack.org, vbabka@suse.cz, akpm@linux-foundation.org, mgorman@techsingularity.net, linux-arm-kernel@lists.infradead.org, osalvador@suse.de, yang.zhang.wz@gmail.com, pagupta@redhat.com, konrad.wilk@oracle.com, nitesh@redhat.com, riel@surriel.com, lcapitulino@redhat.com, wei.w.wang@intel.com, aarcange@redhat.com, pbonzini@redhat.com, dan.j.williams@intel.com, alexander.h.duyck@linux.intel.com Subject: Re: [PATCH v10 0/6] mm / virtio: Provide support for unused page reporting Message-ID: <20190924142342.GX23050@dhcp22.suse.cz> References: <20190918175109.23474.67039.stgit@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190918175109.23474.67039.stgit@localhost.localdomain> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed 18-09-19 10:52:25, Alexander Duyck wrote: [...] > In order to try and keep the time needed to find a non-reported page to > a minimum we maintain a "reported_boundary" pointer. This pointer is used > by the get_unreported_pages iterator to determine at what point it should > resume searching for non-reported pages. In order to guarantee pages do > not get past the scan I have modified add_to_free_list_tail so that it > will not insert pages behind the reported_boundary. > > If another process needs to perform a massive manipulation of the free > list, such as compaction, it can either reset a given individual boundary > which will push the boundary back to the list_head, or it can clear the > bit indicating the zone is actively processing which will result in the > reporting process resetting all of the boundaries for a given zone. Is this any different from the previous version? The last review feedback (both from me and Mel) was that we are not happy to have an externally imposed constrains on how the page allocator is supposed to maintain its free lists. If this is really the only way to go forward then I would like to hear very convincing arguments about other approaches not being feasible. There are none in this cover letter unfortunately. This will be really a hard sell without them. -- Michal Hocko SUSE Labs