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.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 58D09ECDE20 for ; Thu, 12 Sep 2019 07:16:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2FC73214AF for ; Thu, 12 Sep 2019 07:16:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1568272599; bh=jg0ekBBd7viHiLq8tPm9TGNc7PY5WFJZ1o2CJLiCTew=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=HKWMmjhbX6DOTv1d1QV6vQCZ6Hx+acR2tWAnDb9CFUFC7GSOji05Ug7M1+f9LS083 yHUbKSABovODgdLwE/PPrS7ImINt7dkgrGFaDkryhOyefnXrndJ2SDqQ9WtetVjifz 4LyVGsiyxyrVyuZWGHPhvM4/ViiFnwmWZT2DoHAc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729805AbfILHQh (ORCPT ); Thu, 12 Sep 2019 03:16:37 -0400 Received: from mx2.suse.de ([195.135.220.15]:40482 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728927AbfILHQh (ORCPT ); Thu, 12 Sep 2019 03:16:37 -0400 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 DA634AE35; Thu, 12 Sep 2019 07:16:34 +0000 (UTC) Date: Thu, 12 Sep 2019 09:16:33 +0200 From: Michal Hocko To: David Hildenbrand Cc: "Michael S. Tsirkin" , Alexander Duyck , Alexander Duyck , virtio-dev@lists.oasis-open.org, kvm list , Catalin Marinas , 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" Subject: Re: [PATCH v9 0/8] stg mail -e --version=v9 \ Message-ID: <20190912071633.GL4023@dhcp22.suse.cz> References: <20190911113619.GP4023@dhcp22.suse.cz> <20190911080804-mutt-send-email-mst@kernel.org> <20190911121941.GU4023@dhcp22.suse.cz> <20190911122526.GV4023@dhcp22.suse.cz> <4748a572-57b3-31da-0dde-30138e550c3a@redhat.com> <20190911125413.GY4023@dhcp22.suse.cz> <736594d6-b9ae-ddb9-2b96-85648728ef33@redhat.com> <20190911132002.GA4023@dhcp22.suse.cz> <20190911135100.GC4023@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 11-09-19 18:09:18, David Hildenbrand wrote: > On 11.09.19 15:51, Michal Hocko wrote: > > On Wed 11-09-19 15:20:02, Michal Hocko wrote: > > [...] > >>> 4. Continuously report, not the "one time report everything" approach. > >> > >> So you mean the allocator reporting this rather than an external code to > >> poll right? I do not know, how much this is nice to have than must have? > > > > Another idea that I haven't really thought through so it might turned > > out to be completely bogus but let's try anyway. Your "report everything" > > just made me look and realize that free_pages_prepare already performs > > stuff that actually does something similar yet unrelated. > > > > We do report to special page poisoning, zeroying or > > CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address > > space. This sounds like something fitting your model no? > > > > AFAIKS, the poisoning/unmapping is done whenever a page is freed. I > don't quite see yet how that would help to remember if a page was > already reported. Do you still have to differ that state when each page is reported? > After reporting the page we would have to switch some > state (Nitesh: bitmap bit, Alexander: page flag) to identify that. Yes, you can either store the state somewhere. > Of course, we could map the page and treat that as "the state" when we > reported it, but I am not sure that's such a good idea :) > > As always, I might be very wrong ... I still do not fully understand the usecase so I might be equally wrong. My thinking is along these lines. Why should you scan free pages when you can effectively capture each freed page? If you go one step further then post_alloc_hook would be the counterpart to know that your page has been allocated. -- Michal Hocko SUSE Labs 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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, 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 DB16FC5ACAE for ; Thu, 12 Sep 2019 07:16:53 +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 ACBB121479 for ; Thu, 12 Sep 2019 07:16:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="kYWffWxI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ACBB121479 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=nEmuXjiIck2j5zMhTZMb8AhHIbtCy9omRFthn7vtkuM=; b=kYWffWxINoLbxn t3ROm9pcfPnMBGXeuD+JsVhNrD6+bbrjfHCeNWj3Vq3fVlHsCWYjiwQVZfWCIIylmqfXNkJC9/54H v7pR3Tnr6tk1dR2rtlvGizPprJMojSAaUGkAAhv5ve+f5AFeUsB1mqoMfwMBGITz9O+nYQyvc4/qf cXdxWP8sVwqutLPEyp2DvdHqWAZH8eXcvK+gBgaFRKskJjb3WnTwAh1XLShssi0F9zp2pNeyHgyDW XjnQ2kMkFOsHCzSttYrTDxn42DJrFd4fGEYAeVUihv2ycUvX/z/whKPINfx7/ap6ee0el9Zm/eU68 enhi9ysvT2gyxAXFSPAA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.2 #3 (Red Hat Linux)) id 1i8JLN-0003kG-TH; Thu, 12 Sep 2019 07:16:42 +0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by bombadil.infradead.org with esmtps (Exim 4.92.2 #3 (Red Hat Linux)) id 1i8JLJ-0003jl-B2 for linux-arm-kernel@lists.infradead.org; Thu, 12 Sep 2019 07:16:38 +0000 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 DA634AE35; Thu, 12 Sep 2019 07:16:34 +0000 (UTC) Date: Thu, 12 Sep 2019 09:16:33 +0200 From: Michal Hocko To: David Hildenbrand Subject: Re: [PATCH v9 0/8] stg mail -e --version=v9 \ Message-ID: <20190912071633.GL4023@dhcp22.suse.cz> References: <20190911113619.GP4023@dhcp22.suse.cz> <20190911080804-mutt-send-email-mst@kernel.org> <20190911121941.GU4023@dhcp22.suse.cz> <20190911122526.GV4023@dhcp22.suse.cz> <4748a572-57b3-31da-0dde-30138e550c3a@redhat.com> <20190911125413.GY4023@dhcp22.suse.cz> <736594d6-b9ae-ddb9-2b96-85648728ef33@redhat.com> <20190911132002.GA4023@dhcp22.suse.cz> <20190911135100.GC4023@dhcp22.suse.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190912_001637_538816_EB7EEECE X-CRM114-Status: GOOD ( 17.64 ) 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 , "Michael S. Tsirkin" , Catalin Marinas , Alexander Duyck , lcapitulino@redhat.com, linux-mm , Alexander Duyck , will@kernel.org, Andrea Arcangeli , virtio-dev@lists.oasis-open.org, Rik van Riel , Matthew Wilcox , "Wang, Wei W" , ying.huang@intel.com, 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 Wed 11-09-19 18:09:18, David Hildenbrand wrote: > On 11.09.19 15:51, Michal Hocko wrote: > > On Wed 11-09-19 15:20:02, Michal Hocko wrote: > > [...] > >>> 4. Continuously report, not the "one time report everything" approach. > >> > >> So you mean the allocator reporting this rather than an external code to > >> poll right? I do not know, how much this is nice to have than must have? > > > > Another idea that I haven't really thought through so it might turned > > out to be completely bogus but let's try anyway. Your "report everything" > > just made me look and realize that free_pages_prepare already performs > > stuff that actually does something similar yet unrelated. > > > > We do report to special page poisoning, zeroying or > > CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address > > space. This sounds like something fitting your model no? > > > > AFAIKS, the poisoning/unmapping is done whenever a page is freed. I > don't quite see yet how that would help to remember if a page was > already reported. Do you still have to differ that state when each page is reported? > After reporting the page we would have to switch some > state (Nitesh: bitmap bit, Alexander: page flag) to identify that. Yes, you can either store the state somewhere. > Of course, we could map the page and treat that as "the state" when we > reported it, but I am not sure that's such a good idea :) > > As always, I might be very wrong ... I still do not fully understand the usecase so I might be equally wrong. My thinking is along these lines. Why should you scan free pages when you can effectively capture each freed page? If you go one step further then post_alloc_hook would be the counterpart to know that your page has been allocated. -- Michal Hocko SUSE Labs _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel