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.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 A882AC4360C for ; Wed, 2 Oct 2019 23:38:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 47850222BE for ; Wed, 2 Oct 2019 23:38:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="XctgwNUS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 47850222BE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A5F486B0003; Wed, 2 Oct 2019 19:38:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E87D6B0006; Wed, 2 Oct 2019 19:38:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8888D6B0007; Wed, 2 Oct 2019 19:38:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0091.hostedemail.com [216.40.44.91]) by kanga.kvack.org (Postfix) with ESMTP id 5FC856B0003 for ; Wed, 2 Oct 2019 19:38:20 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id EB0FC181AC9AE for ; Wed, 2 Oct 2019 23:38:19 +0000 (UTC) X-FDA: 76000460718.09.blade19_48adc9046a253 X-HE-Tag: blade19_48adc9046a253 X-Filterd-Recvd-Size: 4622 Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Wed, 2 Oct 2019 23:38:19 +0000 (UTC) Received: by mail-lj1-f194.google.com with SMTP id y23so619240lje.9 for ; Wed, 02 Oct 2019 16:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gZjgSIj0qxyD6RaNtViJgY4xf89RohIDwPAnz/d5hI8=; b=XctgwNUSLJVHyx0l1z7HmbUqXz/kLm2tlmec02aPXrV9Mg4o/2cYv7qFPK2f4824Fy huoPbZKRtlv3H5nyAAxtBbaDGrOWa3y+sAgPN1x/k8UITKbzDoFrTzAhN7+ANuYCBttV 48q8QQY3ufyqk60ntMEla2tbGmOT9eQW9m25M= 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=gZjgSIj0qxyD6RaNtViJgY4xf89RohIDwPAnz/d5hI8=; b=U80N0hkztnn8TVf36vZwgxaGrlz5pEhhyCUyOLUNyhQJ0fjN5B2gBRgYh9kfkZ20I6 ieuZelgRGCBhFG2qm6Gj33/1x5elFHDbKZqQdH2jV/QRftQ/1wGzluXx/u2JDYTOtvB/ Jyt8aipAUd3jTs/LatklzMStfifnWlnOqZ1PhuBoEBXajQ71P/OqSUHUTvSNx/mTn56S d9sH8MX/hTgwQCREJZ90PTqxeWL7A4VLOphPGfoy+KTmE1wSTj8pxqU3y4IoNqV99CQc pQvyGh2k8y9gVhMvN9REtTlNwhfiCfoXsZD9MzgaqXWeIwT1+sFaOefVLvedGdomFM2k JiVg== X-Gm-Message-State: APjAAAUi/Ysky489NzwE9J+P5y6qH8khbkDLCexhWwr3qTf6j5CuvYVx D1b5t/rTpOWGalsSxTGPQQWOQcdwasQ= X-Google-Smtp-Source: APXvYqweu6OxtVjRrOO52XnNIyUikvU0ykfCwz4gJDfBvQ0bbwMqtWMKhjpVGrdxTh+rEjT3t8vomw== X-Received: by 2002:a05:651c:295:: with SMTP id b21mr1527958ljo.244.1570059497487; Wed, 02 Oct 2019 16:38:17 -0700 (PDT) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com. [209.85.208.177]) by smtp.gmail.com with ESMTPSA id j28sm93845lfh.57.2019.10.02.16.38.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Oct 2019 16:38:13 -0700 (PDT) Received: by mail-lj1-f177.google.com with SMTP id v24so653123ljj.3 for ; Wed, 02 Oct 2019 16:38:13 -0700 (PDT) X-Received: by 2002:a2e:551:: with SMTP id 78mr4178421ljf.48.1570059493007; Wed, 02 Oct 2019 16:38:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Wed, 2 Oct 2019 16:37:57 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [rfc] mm, hugetlb: allow hugepage allocations to excessively reclaim To: David Rientjes Cc: Mike Kravetz , Michal Hocko , Vlastimil Babka , Andrea Arcangeli , Andrew Morton , Mel Gorman , "Kirill A. Shutemov" , Linux Kernel Mailing List , 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 Wed, Oct 2, 2019 at 4:03 PM David Rientjes wrote: > > Since hugetlb allocations have explicitly preferred to loop and do reclaim > and compaction, exempt them from this new behavior at least for the time > being. It is not shown that hugetlb allocation success rate has been > impacted by commit b39d0ee2632d but hugetlb allocations are admittedly > beyond the scope of what the patch is intended to address (thp > allocations). I'd like to see some numbers to show that this special case makes sense. I understand the "this is what it used to do, and hugetlbfs wasn't the intended recipient of the new semantics", and I don't think the patch is wrong. But at the same time, we do know that swap storms happen for other loads, and if we say "hugetlbfs is different" then there should at least be some rationale for why it's different other than "history". Some actual "yes, we _want_ the possibile swap storms, because load XYZ". And I don't mean microbenchmark numbers for "look, behavior changed". I mean "look, this is a real load, and now it runs X% slower because it relied on this hugetlbfs behavior". Linus