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.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 4E701FC6194 for ; Wed, 6 Nov 2019 23:39:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F1528207FA for ; Wed, 6 Nov 2019 23:39:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Hfgk3UQp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F1528207FA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 95BF56B0005; Wed, 6 Nov 2019 18:39:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 90C4D6B0006; Wed, 6 Nov 2019 18:39:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 822396B0007; Wed, 6 Nov 2019 18:39:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0035.hostedemail.com [216.40.44.35]) by kanga.kvack.org (Postfix) with ESMTP id 6BE746B0005 for ; Wed, 6 Nov 2019 18:39:03 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id CE638181AEF10 for ; Wed, 6 Nov 2019 23:39:02 +0000 (UTC) X-FDA: 76127470524.15.house12_4eeff6d24db4b X-HE-Tag: house12_4eeff6d24db4b X-Filterd-Recvd-Size: 6956 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Wed, 6 Nov 2019 23:39:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573083541; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=P7ECVmmM8vIgSNXp3Z5vTM/IVAUjQ4kqES+QOZV+6pM=; b=Hfgk3UQp4rBiWfAXzACvUWDwQkQnAPb8bx1gRXtNzhNw8Vw/gwmNarwDMo7wL87R5TQvOO os8hPo0/CqltPr6yhkYvxB/26h2xKiYM3v3lcCZIhzrSnJSXh8YTQjJWYyrdWI8IfraE/N o0WDICVTi2VP+8pmGdHdeoDUieZxWxM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-4-ou7Eg7a-OOO0QkCrcAFiJQ-1; Wed, 06 Nov 2019 18:38:55 -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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id A11A0800C73; Wed, 6 Nov 2019 23:38:53 +0000 (UTC) Received: from [10.36.116.42] (ovpn-116-42.ams2.redhat.com [10.36.116.42]) by smtp.corp.redhat.com (Postfix) with ESMTP id 931E5600CD; Wed, 6 Nov 2019 23:38:43 +0000 (UTC) Subject: Re: + mm-introduce-reported-pages.patch added to -mm tree To: Mel Gorman , Alexander Duyck Cc: Michal Hocko , akpm@linux-foundation.org, aarcange@redhat.com, dan.j.williams@intel.com, dave.hansen@intel.com, konrad.wilk@oracle.com, lcapitulino@redhat.com, mm-commits@vger.kernel.org, mst@redhat.com, osalvador@suse.de, pagupta@redhat.com, pbonzini@redhat.com, riel@surriel.com, vbabka@suse.cz, wei.w.wang@intel.com, willy@infradead.org, yang.zhang.wz@gmail.com, linux-mm@kvack.org References: <20191106121605.GH8314@dhcp22.suse.cz> <20191106165416.GO8314@dhcp22.suse.cz> <20191106221150.GR3016@techsingularity.net> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: Date: Thu, 7 Nov 2019 00:38:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <20191106221150.GR3016@techsingularity.net> Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: ou7Eg7a-OOO0QkCrcAFiJQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable 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: >>> I definitely do not intent to nack this work, I just have maintainabili= ty >>> concerns and considering there is an alternative approach that does not >>> require to touch page allocator internals and which we need to compare >>> against then I do not really think there is any need to push something >>> in right away. Or is there any pressing reason to have this merged righ= t >>> now? >> >> The alternative approach doesn't touch the page allocator, however it >> still has essentially the same changes to __free_one_page. I suspect the >> performance issue seen is mostly due to the fact that because it doesn't >> touch the page allocator it is taking the zone lock and probing the page >> for each set bit to see if the page is still free. As such the performan= ce >> regression seen gets worse the lower the order used for reporting. >> >=20 > What confused me quite a lot is that this is enabled at compile time > and then incurs a performance hit whether there is a hypervisor that > even cares is involved or not. So I don't think the performance angle > justifying this approach is a good one because this implementation has > issues of its own. Previously I said >=20 > =09I worry that poking too much into the internal state of the > =09allocator will be fragile long-term. There is the arch alloc/free > =09hooks but they are typically about protections only and does not > =09interfere with the internal state of the allocator. Compaction > =09pokes in as well but once the page is off the free list, the page > =09allocator no longer cares so again there is on interference with > =09the internal state. If the state is interefered with externally, > =09it becomes unclear what happens if things like page merging is > =09deferred in a way the allocator cannot control as high-order > =09allocation requests may fail for example. >=20 > Adding an API for compaction does not get away from the problem that > it'll be fragile to depend on the internal state of the allocator for > correctness. Existing users that poke into the state do so as an > optimistic shortcut but if it fails, nothing actually breaks. The free > list reporting stuff might and will not be routinely tested. >=20 > Take compaction as an example, the initial implementation of it was dumb > as rocks and only started maintaining additional state and later poking > into the page allocator when there was empirical evidence it was necessar= y. >=20 > The initial implementation of page reporting should be the same, it > should do no harm at all to users that don't care (hiding behind > kconfig is not good enough, use static branches) and it should not > depend on the internal state of the page allocator and ordering of free > lists for correctness until it's shown it's absolutely necessary. >=20 > You say that the zone lock has to be taken in the alternative > implementation to check if it's still free and sure, that would cost > but unless you are isolating that page immediately then you are racing > once the lock is released. If you are isolating immediately, then isolate > pages in batches to amortise the loock costs. The details of this could > be really hard but this approach is essentially saying "everything, > everywhere should take a small hit so the overhead is not noticeable for > virtio users" which is a curious choice for a new feature. >=20 > Regardless of the details of any implementation, the first one should be > basic, do no harm and be relatively simple giving just a bare interface > to virtio/qemu/etc. Then optimise it until such point as there is no > chance but to poke into the core. I second that. If somebody would ask me, I'd want to see a simple,=20 maintainable design that provides a net benefit, does not harm !virt and=20 possibly reuses existing core functionality (e.g., page isolation). We=20 can work from there to optimize. --=20 Thanks, David / dhildenb