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.7 required=3.0 tests=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 1C4A5C433DF for ; Tue, 16 Jun 2020 17:03:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DA608208E4 for ; Tue, 16 Jun 2020 17:03:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="bBaItCjy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DA608208E4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5E6E88D0023; Tue, 16 Jun 2020 13:03:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 597A48D0006; Tue, 16 Jun 2020 13:03:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4ACB38D0023; Tue, 16 Jun 2020 13:03:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0123.hostedemail.com [216.40.44.123]) by kanga.kvack.org (Postfix) with ESMTP id 2F3BD8D0006 for ; Tue, 16 Jun 2020 13:03:48 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id BDA33CA34E for ; Tue, 16 Jun 2020 17:03:47 +0000 (UTC) X-FDA: 76935696894.21.cow47_0205cfc26e00 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id CF06B18EEC7BC for ; Tue, 16 Jun 2020 17:03:44 +0000 (UTC) X-HE-Tag: cow47_0205cfc26e00 X-Filterd-Recvd-Size: 4956 Received: from mail-ed1-f68.google.com (mail-ed1-f68.google.com [209.85.208.68]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Tue, 16 Jun 2020 17:03:43 +0000 (UTC) Received: by mail-ed1-f68.google.com with SMTP id t21so14817948edr.12 for ; Tue, 16 Jun 2020 10:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9xjk5DzZyjpoB1GSJ8tZz8huXPpW+bXfr81ISG5HVdc=; b=bBaItCjyqIeraEzbLMVwYMyHRe013T+gzyWOqvfnQYNP+wnSHONozCb4pfAg4GVN8j jxppjlufBxsiv2qc9vo0azuW47QUZMXH3FMxb3RRDIQpQdS9i+KMZcMkJgTuU3D3MYLN pKpUjLjoKTz/Ql3auxIlClwJ4AULPwNGuvKd3ClWPx0hH0vjNike46+lF+JdNAkvtrFl PGkPOaYR5Y29app4UZHUICuPi2Qf1JlJl5jPUVR9/P/JgF7pi9BbjRcuDDYbBr3NxK06 BhuUzZnq1dDVgwGzSx2+QrsVEfXtK+GhhRXsOyJvp6T0xA1woV4PjLWS6zWO1RKsPMXp B+SQ== 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=9xjk5DzZyjpoB1GSJ8tZz8huXPpW+bXfr81ISG5HVdc=; b=E1c0V12UyZf75sif/f4VoTT5De1V0X0h6eYXY89PWEXaUHN1i/647qUyX/uqDGp2u/ qabBILCfoDEVbuULEt4dYARRe8/sHSkkIZUtla1Z8PaY35N9gylsbflkTW4YaPWNJ5tm XtIJZ/Yw47pQw2enkYKdA8fcDmE7dwBRpkGnezKpTyFIdXC7CDj5D/HJxPvx9PODvpxC rT0ElYirsh7KicxTalfwvE4NfxiwY3WdzZ/1wNCterxpis3cgNfVOdJ7KuPUByVkrtcZ b5TVPuLeLxmZW5qwN0U1cBsN5g839p2Dk8EVCjGEeEnrTCc4iSt69vkhxWc6gBa+yv3J j6Qw== X-Gm-Message-State: AOAM533yy7iTJs8yTHmSBBetwQMQQU2spD+eF1utVqc8/Mz1nnNf4PdM FwZ2vmXj2QE0qvlIw9sAhTVhshEsTz1+P2I9rKkGjg== X-Google-Smtp-Source: ABdhPJzJldCKyqNV/8NHFDtnfKWWcbuB+diPaO82MWlkxKKsCb133mLWTtMSKim2glwNE97g5peGu56W8VgQfaSD/Rg= X-Received: by 2002:a05:6402:459:: with SMTP id p25mr1587716edw.383.1592327022502; Tue, 16 Jun 2020 10:03:42 -0700 (PDT) MIME-Version: 1.0 References: <20200616115213.13109-1-david@redhat.com> <20200616115213.13109-3-david@redhat.com> <20200616125051.GH9499@dhcp22.suse.cz> In-Reply-To: From: Dan Williams Date: Tue, 16 Jun 2020 10:03:31 -0700 Message-ID: Subject: Re: [PATCH v1 2/3] mm/memory_hotplug: don't shuffle complete zone when onlining memory To: Michal Hocko Cc: David Hildenbrand , Linux Kernel Mailing List , Linux MM , Andrew Morton , Alexander Duyck , Dave Hansen , Kees Cook , Mel Gorman Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: CF06B18EEC7BC X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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, Jun 16, 2020 at 10:00 AM Dan Williams wrote: > > On Tue, Jun 16, 2020 at 5:51 AM Michal Hocko wrote: > > > > On Tue 16-06-20 13:52:12, David Hildenbrand wrote: > > > Commit e900a918b098 ("mm: shuffle initial free memory to improve > > > memory-side-cache utilization") introduced shuffling of free pages > > > during system boot and whenever we online memory blocks. > > > > > > However, whenever we online memory blocks, all pages that will be > > > exposed to the buddy end up getting freed via __free_one_page(). In the > > > general case, we free these pages in MAX_ORDER - 1 chunks, which > > > corresponds to the shuffle order. > > > > > > Inside __free_one_page(), we will already shuffle the newly onlined pages > > > using "to_tail = shuffle_pick_tail();". Drop explicit zone shuffling on > > > memory hotplug. This was already explained in the initial patch submission. The shuffle_pick_tail() shuffling at run time is only sufficient for maintaining the shuffle. It's not sufficient for effectively randomizing the free list. See: e900a918b098 mm: shuffle initial free memory to improve memory-side-cache utilization This initial randomization can be undone over time so a follow-on patch is introduced to inject entropy on page free decisions. It is reasonable to ask if the page free entropy is sufficient, but it is not enough due to the in-order initial freeing of pages. At the start of that process putting page1 in front or behind page0 still keeps them close together, page2 is still near page1 and has a high chance of being adjacent. As more pages are added ordering diversity improves, but there is still high page locality for the low address pages and this leads to no significant impact to the cache conflict rate.