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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 1114AC49ED7 for ; Tue, 10 Sep 2019 20:37:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E108C2168B for ; Tue, 10 Sep 2019 20:37:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726329AbfIJUht (ORCPT ); Tue, 10 Sep 2019 16:37:49 -0400 Received: from mga12.intel.com ([192.55.52.136]:57487 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725770AbfIJUhs (ORCPT ); Tue, 10 Sep 2019 16:37:48 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Sep 2019 13:37:48 -0700 X-IronPort-AV: E=Sophos;i="5.64,490,1559545200"; d="scan'208";a="175432349" Received: from ahduyck-desk1.jf.intel.com ([10.7.198.76]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Sep 2019 13:37:48 -0700 Message-ID: <9b1c34e8b846e2d9ede6879bce47c7d704c89bd3.camel@linux.intel.com> Subject: Re: [PATCH v9 0/8] stg mail -e --version=v9 \ From: Alexander Duyck To: Michal Hocko , Alexander Duyck Cc: virtio-dev@lists.oasis-open.org, kvm list , "Michael S. Tsirkin" , Catalin Marinas , David Hildenbrand , Dave Hansen , LKML , Matthew Wilcox , linux-mm , Andrew Morton , will@kernel.org, linux-arm-kernel@lists.infradead.org, Oscar Salvador , Yang Zhang , Pankaj Gupta , Konrad Rzeszutek Wilk , Nitesh Narayan Lal , Rik van Riel , lcapitulino@redhat.com, "Wang, Wei W" , Andrea Arcangeli , ying.huang@intel.com, Paolo Bonzini , Dan Williams , Fengguang Wu , "Kirill A. Shutemov" Date: Tue, 10 Sep 2019 13:37:47 -0700 In-Reply-To: <20190910180026.GE4023@dhcp22.suse.cz> References: <20190907172225.10910.34302.stgit@localhost.localdomain> <20190910124209.GY2063@dhcp22.suse.cz> <20190910144713.GF2063@dhcp22.suse.cz> <20190910175213.GD4023@dhcp22.suse.cz> <20190910180026.GE4023@dhcp22.suse.cz> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2019-09-10 at 20:00 +0200, Michal Hocko wrote: > On Tue 10-09-19 19:52:13, Michal Hocko wrote: > > On Tue 10-09-19 09:05:43, Alexander Duyck wrote: > [...] > > > All this is providing is just a report and it is optional if the > > > hypervisor will act on it or not. If the hypervisor takes some sort of > > > action on the page, then the expectation is that the hypervisor will > > > use some sort of mechanism such as a page fault to discover when the > > > page is used again. > > > > OK so the baloon driver is in charge of this metadata and the allocator > > has to live with that. Isn't that a layer violation? > > Another thing that is not clear to me is how these marked pages are > different from any other free pages. All of them are unused and you are > losing your metadata as soon as the page gets allocated because the page > changes its owner and the struct page belongs to it. Really they aren't any different then other free pages other than they are marked. Us losing the metadata as soon as the page is allocated is fine as we will need to re-report it when it is returned so we no longer need the metadata once it is allocated. 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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 6E5E0C49ED7 for ; Tue, 10 Sep 2019 20:37:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3A978216F4 for ; Tue, 10 Sep 2019 20:37:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3A978216F4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CC4626B0007; Tue, 10 Sep 2019 16:37:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C75136B0008; Tue, 10 Sep 2019 16:37:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B64836B000A; Tue, 10 Sep 2019 16:37:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0133.hostedemail.com [216.40.44.133]) by kanga.kvack.org (Postfix) with ESMTP id 953DE6B0007 for ; Tue, 10 Sep 2019 16:37:50 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 3982B180AD804 for ; Tue, 10 Sep 2019 20:37:50 +0000 (UTC) X-FDA: 75920172300.13.hat34_7e8ca20454861 X-HE-Tag: hat34_7e8ca20454861 X-Filterd-Recvd-Size: 3723 Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Tue, 10 Sep 2019 20:37:49 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Sep 2019 13:37:48 -0700 X-IronPort-AV: E=Sophos;i="5.64,490,1559545200"; d="scan'208";a="175432349" Received: from ahduyck-desk1.jf.intel.com ([10.7.198.76]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Sep 2019 13:37:48 -0700 Message-ID: <9b1c34e8b846e2d9ede6879bce47c7d704c89bd3.camel@linux.intel.com> Subject: Re: [PATCH v9 0/8] stg mail -e --version=v9 \ From: Alexander Duyck To: Michal Hocko , Alexander Duyck Cc: virtio-dev@lists.oasis-open.org, kvm list , "Michael S. Tsirkin" , Catalin Marinas , David Hildenbrand , Dave Hansen , LKML , Matthew Wilcox , linux-mm , Andrew Morton , will@kernel.org, linux-arm-kernel@lists.infradead.org, Oscar Salvador , Yang Zhang , Pankaj Gupta , Konrad Rzeszutek Wilk , Nitesh Narayan Lal , Rik van Riel , lcapitulino@redhat.com, "Wang, Wei W" , Andrea Arcangeli , ying.huang@intel.com, Paolo Bonzini , Dan Williams , Fengguang Wu , "Kirill A. Shutemov" Date: Tue, 10 Sep 2019 13:37:47 -0700 In-Reply-To: <20190910180026.GE4023@dhcp22.suse.cz> References: <20190907172225.10910.34302.stgit@localhost.localdomain> <20190910124209.GY2063@dhcp22.suse.cz> <20190910144713.GF2063@dhcp22.suse.cz> <20190910175213.GD4023@dhcp22.suse.cz> <20190910180026.GE4023@dhcp22.suse.cz> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 Tue, 2019-09-10 at 20:00 +0200, Michal Hocko wrote: > On Tue 10-09-19 19:52:13, Michal Hocko wrote: > > On Tue 10-09-19 09:05:43, Alexander Duyck wrote: > [...] > > > All this is providing is just a report and it is optional if the > > > hypervisor will act on it or not. If the hypervisor takes some sort of > > > action on the page, then the expectation is that the hypervisor will > > > use some sort of mechanism such as a page fault to discover when the > > > page is used again. > > > > OK so the baloon driver is in charge of this metadata and the allocator > > has to live with that. Isn't that a layer violation? > > Another thing that is not clear to me is how these marked pages are > different from any other free pages. All of them are unused and you are > losing your metadata as soon as the page gets allocated because the page > changes its owner and the struct page belongs to it. Really they aren't any different then other free pages other than they are marked. Us losing the metadata as soon as the page is allocated is fine as we will need to re-report it when it is returned so we no longer need the metadata once it is allocated. 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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 88939C49ED7 for ; Tue, 10 Sep 2019 20:37:58 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 584D22168B for ; Tue, 10 Sep 2019 20:37:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="aFNYTz6c" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 584D22168B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=IdEUpgxOiCCF702NrUpz0JfX8O0fNlDX3IP/Q3tiAOI=; b=aFNYTz6cnXyYcm dhw3PaRZunRUGEdJIVavHsVuS1cWT8aRtf1MWlGFOQw+yeF5qN9hskWXw0tfsT9xrtT7FMZko2D9+ Ghi5rpfU74nYVuLkmh27fRYZo28j4a/OzrZt5EledAGh4FWsrxGGHzaqcdgcIO7E/IuD2UbInJ7fj 7HAaBIGsSYFeJT7ldFigJpu/KYpev96dtbY8IxEqsq2LXpZzo6g4Rb0zD8PpwJvZFALcIAUxhIVfu w1VkGKaclAu1InTLP2ayDr7ovVehWoLFz2Z8TbfUgJi4J3cRb59sqm6mZNxZ1DrAWg4jaiE2IW/Au cq3UtEIiQYHZLdAAi79Q==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i7mtc-0004kV-Kw; Tue, 10 Sep 2019 20:37:52 +0000 Received: from mga09.intel.com ([134.134.136.24]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1i7mtY-0004k4-Nq for linux-arm-kernel@lists.infradead.org; Tue, 10 Sep 2019 20:37:49 +0000 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Sep 2019 13:37:48 -0700 X-IronPort-AV: E=Sophos;i="5.64,490,1559545200"; d="scan'208";a="175432349" Received: from ahduyck-desk1.jf.intel.com ([10.7.198.76]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Sep 2019 13:37:48 -0700 Message-ID: <9b1c34e8b846e2d9ede6879bce47c7d704c89bd3.camel@linux.intel.com> Subject: Re: [PATCH v9 0/8] stg mail -e --version=v9 \ From: Alexander Duyck To: Michal Hocko , Alexander Duyck Date: Tue, 10 Sep 2019 13:37:47 -0700 In-Reply-To: <20190910180026.GE4023@dhcp22.suse.cz> References: <20190907172225.10910.34302.stgit@localhost.localdomain> <20190910124209.GY2063@dhcp22.suse.cz> <20190910144713.GF2063@dhcp22.suse.cz> <20190910175213.GD4023@dhcp22.suse.cz> <20190910180026.GE4023@dhcp22.suse.cz> User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190910_133748_819164_1677633D X-CRM114-Status: GOOD ( 15.71 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Yang Zhang , Pankaj Gupta , kvm list , David Hildenbrand , Catalin Marinas , lcapitulino@redhat.com, linux-mm , will@kernel.org, Andrea Arcangeli , virtio-dev@lists.oasis-open.org, "Michael S. Tsirkin" , Matthew Wilcox , "Wang, Wei W" , ying.huang@intel.com, Rik van Riel , Konrad Rzeszutek Wilk , Dan Williams , linux-arm-kernel@lists.infradead.org, Oscar Salvador , Nitesh Narayan Lal , Dave Hansen , LKML , Paolo Bonzini , Andrew Morton , Fengguang Wu , "Kirill A. Shutemov" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 2019-09-10 at 20:00 +0200, Michal Hocko wrote: > On Tue 10-09-19 19:52:13, Michal Hocko wrote: > > On Tue 10-09-19 09:05:43, Alexander Duyck wrote: > [...] > > > All this is providing is just a report and it is optional if the > > > hypervisor will act on it or not. If the hypervisor takes some sort of > > > action on the page, then the expectation is that the hypervisor will > > > use some sort of mechanism such as a page fault to discover when the > > > page is used again. > > > > OK so the baloon driver is in charge of this metadata and the allocator > > has to live with that. Isn't that a layer violation? > > Another thing that is not clear to me is how these marked pages are > different from any other free pages. All of them are unused and you are > losing your metadata as soon as the page gets allocated because the page > changes its owner and the struct page belongs to it. Really they aren't any different then other free pages other than they are marked. Us losing the metadata as soon as the page is allocated is fine as we will need to re-report it when it is returned so we no longer need the metadata once it is allocated. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-6107-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 052B0985BF8 for ; Tue, 10 Sep 2019 20:37:50 +0000 (UTC) Message-ID: <9b1c34e8b846e2d9ede6879bce47c7d704c89bd3.camel@linux.intel.com> From: Alexander Duyck Date: Tue, 10 Sep 2019 13:37:47 -0700 In-Reply-To: <20190910180026.GE4023@dhcp22.suse.cz> References: <20190907172225.10910.34302.stgit@localhost.localdomain> <20190910124209.GY2063@dhcp22.suse.cz> <20190910144713.GF2063@dhcp22.suse.cz> <20190910175213.GD4023@dhcp22.suse.cz> <20190910180026.GE4023@dhcp22.suse.cz> Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \ To: Michal Hocko , Alexander Duyck Cc: virtio-dev@lists.oasis-open.org, kvm list , "Michael S. Tsirkin" , Catalin Marinas , David Hildenbrand , Dave Hansen , LKML , Matthew Wilcox , linux-mm , Andrew Morton , will@kernel.org, linux-arm-kernel@lists.infradead.org, Oscar Salvador , Yang Zhang , Pankaj Gupta , Konrad Rzeszutek Wilk , Nitesh Narayan Lal , Rik van Riel , lcapitulino@redhat.com, "Wang, Wei W" , Andrea Arcangeli , ying.huang@intel.com, Paolo Bonzini , Dan Williams , Fengguang Wu , "Kirill A. Shutemov" List-ID: On Tue, 2019-09-10 at 20:00 +0200, Michal Hocko wrote: > On Tue 10-09-19 19:52:13, Michal Hocko wrote: > > On Tue 10-09-19 09:05:43, Alexander Duyck wrote: > [...] > > > All this is providing is just a report and it is optional if the > > > hypervisor will act on it or not. If the hypervisor takes some sort of > > > action on the page, then the expectation is that the hypervisor will > > > use some sort of mechanism such as a page fault to discover when the > > > page is used again. > > > > OK so the baloon driver is in charge of this metadata and the allocator > > has to live with that. Isn't that a layer violation? > > Another thing that is not clear to me is how these marked pages are > different from any other free pages. All of them are unused and you are > losing your metadata as soon as the page gets allocated because the page > changes its owner and the struct page belongs to it. Really they aren't any different then other free pages other than they are marked. Us losing the metadata as soon as the page is allocated is fine as we will need to re-report it when it is returned so we no longer need the metadata once it is allocated. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org