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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 E697BC43331 for ; Sun, 10 Nov 2019 18:04:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7DEC520842 for ; Sun, 10 Nov 2019 18:04:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jlW4URJg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7DEC520842 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B267B6B0003; Sun, 10 Nov 2019 13:04:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AD75F6B0006; Sun, 10 Nov 2019 13:04:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A15646B0007; Sun, 10 Nov 2019 13:04:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0142.hostedemail.com [216.40.44.142]) by kanga.kvack.org (Postfix) with ESMTP id 8C9CF6B0003 for ; Sun, 10 Nov 2019 13:04:05 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 1FF238249980 for ; Sun, 10 Nov 2019 18:04:05 +0000 (UTC) X-FDA: 76141141650.06.heart69_684217468132 X-HE-Tag: heart69_684217468132 X-Filterd-Recvd-Size: 7912 Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Sun, 10 Nov 2019 18:04:04 +0000 (UTC) Received: by mail-il1-f177.google.com with SMTP id z12so9811620ilp.2 for ; Sun, 10 Nov 2019 10:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TJ94PksGQb6ipV2IRxUA5jdP1fNaJSsOudhGdGk1ysY=; b=jlW4URJgJABcKAhD7+6bkYrYAtSObOZ3ftQqQpLI0u19UF1w4A2L43Bnog/dPI4EI8 ntloze2mTDKP1RDHYCmUJoAjNkzM0o1eTd7xiR8YQqb1Yuqh7jiGeQvKh9p02U+yo5G9 WnTdxvGBmsQgZ73bNr1jeycbzqZYU/4PBux2B5iisB/4iCGx/4OP3y36PbAQ3zlD3cWx mr1NNNnN0LTgQHdkyFnfOzKyqextV8atb0OsZdohf8wco183Jftteu+WQGdUA6RQL/W5 SI+CwtwtGZVu1QBxq0eFVluN2kOwNMyYuBAuhtTRBJwVGNuomEHz7WxA2zhrvrqMWsRm AY8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TJ94PksGQb6ipV2IRxUA5jdP1fNaJSsOudhGdGk1ysY=; b=G7Ul1RyHPhVI+LTyaM5MZuHsGHg+rHwFwQ0AC7oakmgiRDBF/6KSH9gP8MQI+vqQPR sr9tbj7Y7ek4rbdGQUZqBYyXqDcsaoAUhXZi8l7yOQlr/SOeMPYYkgiTLo7JJQt0Rs/n X/AR00CjxCXwBYNZyFucVb6K2FYCJwcnxTA2X94jQvzghFugkjXz/W2mcdrxI51K/2Ko mLoE2llUy00z5IAlVjljHpMrzeGvJG6uuKSNwIClfoADViaEvOLU0r2DxszHrWMQECTg 6+cR5CHwEjtc8zBd6w321/7US6d+9dHQdqwsBT1z+q3W0tHadTl1EpO1Qup5gebNQfuI bwqA== X-Gm-Message-State: APjAAAXKYeDiGYU4+4IcUEH+q10/jyyG68lSi1b+qX4Zoe2sWhMMF13D psGx48IAcLUztEA3MIcaqo3fT/021PVEgfz6A7k= X-Google-Smtp-Source: APXvYqzdKx49F2qfjttSlbTh/dqzi4RUKDA+ZLk7o4kqCdHXR1zrY9BwMQ4CYgolvbLF5wtIY4yOT8QDBVQqQMDnXi8= X-Received: by 2002:a92:9f1c:: with SMTP id u28mr24442102ili.97.1573409043742; Sun, 10 Nov 2019 10:04:03 -0800 (PST) MIME-Version: 1.0 References: <20191106165416.GO8314@dhcp22.suse.cz> <20191106221150.GR3016@techsingularity.net> <673862eb7f0425f638ea3fc507d0e8049ee4133c.camel@linux.intel.com> <20191107102045.GS3016@techsingularity.net> <73c0477e6e1672d5d36d4aa673b64cda10590a9d.camel@linux.intel.com> <20191108094340.GT3016@techsingularity.net> <4c3e787b5db923de8599eafee46c1235eacd2432.camel@linux.intel.com> <20191108184124.GV3016@techsingularity.net> <3161e0ec205852f8fcd1559f2dc177e42549708b.camel@linux.intel.com> <20191109145752.GW3016@techsingularity.net> In-Reply-To: <20191109145752.GW3016@techsingularity.net> From: Alexander Duyck Date: Sun, 10 Nov 2019 10:03:52 -0800 Message-ID: Subject: Re: + mm-introduce-reported-pages.patch added to -mm tree To: Mel Gorman Cc: Alexander Duyck , Michal Hocko , David Hildenbrand , Andrew Morton , Andrea Arcangeli , Dan Williams , Dave Hansen , Konrad Rzeszutek Wilk , lcapitulino@redhat.com, mm-commits@vger.kernel.org, "Michael S. Tsirkin" , Oscar Salvador , Pankaj Gupta , Paolo Bonzini , Rik van Riel , Vlastimil Babka , "Wang, Wei W" , Matthew Wilcox , Yang Zhang , linux-mm Content-Type: text/plain; charset="UTF-8" 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 Sat, Nov 9, 2019 at 6:57 AM Mel Gorman wrote: > > On Fri, Nov 08, 2019 at 12:29:47PM -0800, Alexander Duyck wrote: > > On Fri, 2019-11-08 at 18:41 +0000, Mel Gorman wrote: > > > On Fri, Nov 08, 2019 at 08:17:49AM -0800, Alexander Duyck wrote: > > > > > > > > > > > > > > > From your perspective, I see it's a bit annoying because in the final > > > > > result, the code should be identical. However, it'll be a lot clearer > > > > > during review what is required, what level of complexity optimisations > > > > > add and the performance of it. The changelog should include what metric > > > > > you are using to evaluate the performance, the test case and the delta. It > > > > > also will be easier from a debugging perspective as minimally a bisection > > > > > could identify if a bug was due to the core mechanism itself or one of > > > > > the optimisations. Finally, it leaves open the possibility that someone > > > > > can evaluate a completely different set of optimisations. Whatever the > > > > > alternative approaches are, the actual interface to virtio ballon surely > > > > > is the same (I don't actually know, I just can't see why the virtio ABI > > > > > would be depend on how the pages are isolated, tracked and reported). > > > > > > > > The virtio-balloon interface is the same at this point between my solution > > > > and Nitesh's. So the only real disagreement in terms of the two solutions > > > > is about keeping the bit in the page and the list manipulation versus the > > > > external bitmap and the hunt and peck approach. > > > > > > > > > > This is good news because it means that when/if Nitesh's approach is ready > > > that the optimisations can be reverted and the new approach applied and > > > give a like-like comparison if appropriate. The core feature and interface > > > to userspace would remain the same and stay available regardless of how > > > it's optimised. Maybe it's the weekend talking but I think structuring > > > the series like that will allow forward progress to be made. > > > > So quick question. > > > > Any issue with me manipulating the lists like you do with the compaction > > code? I ask because most of the overhead I was encountering was likely due > > to walking the list so many times. > > That doesn't surprise me because it was necessary for the fast isolation > in compaction to reduce the overhead when compaction was running at > high frequency. > > > If I do the split/splice style logic > > that should reduce the total number of trips through the free lists since > > I could push the reported pages to the tail of the list. For now I am > > working on that as an alternate patch to the existing reported_boundary > > approach just as an experiment. > > I don't have a problem with that although it should be split out and shared > between compaction and the virtio balloon if possible. The consequences > are that compaction and the balloon might interfere with each other. That > would increase the overhead of compaction and the balloon if they both > were running at the same time. However, given that the balloon will have > a performance impact anyway, I don't think it's worth worrying about > because functionally it should be fine. Actually I may have found a better alternative to achieve the same solution. It looks like there was a function called list_rotate_to_front for dealing with issues like this. Instead of the complicated logic that was used in the compaction code this seems like this might be a better fit as it is pretty simple to use. The only check I have to throw in is one to test for if the entry is first or not, if not then we basically pluck the head of the list out and plant it right in front of the page we want to process on the next iteration. Results so far seem promising. The performance for the non-shuffle case is on par with the v13 set, and I am testing the shuffle case now as I suspect that one will likely show more of a regression. Thanks. - Alex