Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2997666imm; Mon, 24 Sep 2018 13:47:10 -0700 (PDT) X-Google-Smtp-Source: ACcGV62vPEqJkpKh1k0SKpNOZuOweFJjOt7WtJpA7o+9t5q7bcsyHZuYiXGnxEkU4gft4Z+KJq2K X-Received: by 2002:a63:eb0e:: with SMTP id t14-v6mr441887pgh.198.1537822030548; Mon, 24 Sep 2018 13:47:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537822030; cv=none; d=google.com; s=arc-20160816; b=hmPzhag/VLdQ3wxNh+o1ygQijfJ1m/UujACysdceBht5Pw/BMgCTwZSsVWQnP0mROI AHBrinzrCWAcZlSRDf3KBlzkxiloTvOODHGLz9kzQ8SSmbqXaeW4EaiECRcRRbk47Mwy mzaoiA8bZCJ6mq5q/rhxUuKKGc7KT3GaMdsQsRd/33U8hZdoZSe63wgsAoJRjzOvD5VU 8htJIDqHsbRWz7jOYzXW6CNZ/Ltj28vHeAsaiMZ3X670YbObhl42MCMg7H6wxQTZqXKE Dp0VppW6C1UjfHePxkDPd5ixKxwmIhb2u7nmRYYtty40a8CTKoKWVayM6lwnhc3bKCm+ V7FA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:autocrypt:openpgp:from:references:cc:to:subject; bh=r/rTo3cigxYQaRfd8AFg7bYUByAwbkuKr9N5fsmLlRo=; b=oejZqfzgslh/eNMsoiFy6bBDNUH0bfArl8Siov57CiMlCI1yqJhOW8cvoKOFWMTfap 6iPcLO4xbS55GFngzo4SJaKhphsx1Pr4XWTUkBV3CVljrGKjLPzyiduhnZfsHGqAI9Jf vdsCju8tW5jno8PQFrcP0P4tMrH/ac/j9L3sjxA7IRgUF/TGwZL1LlR6y1cL82S3PHEo wMLdUMLyUL6mHawUxyqzh9qVJqVLW4rjV3oOiyZbE9PrNyfBdID8A4xZ1GoudTZsNpDV 7bdR0T9ToYd/Gipd8x1pnAgSlDY3pKFcG0PaFXyArE15rDWaOvC2ZkqaAPAtmeItr7Sm V2PQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id be5-v6si267147plb.67.2018.09.24.13.46.54; Mon, 24 Sep 2018 13:47:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728028AbeIYCub (ORCPT + 99 others); Mon, 24 Sep 2018 22:50:31 -0400 Received: from mx2.suse.de ([195.135.220.15]:33964 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727839AbeIYCub (ORCPT ); Mon, 24 Sep 2018 22:50:31 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 78077AF7F; Mon, 24 Sep 2018 20:46:27 +0000 (UTC) Subject: Re: [patch v2] mm, thp: always specify ineligible vmas as nh in smaps To: Michal Hocko , David Rientjes Cc: Andrew Morton , Alexey Dobriyan , "Kirill A. Shutemov" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-api@vger.kernel.org References: <20180924195603.GJ18685@dhcp22.suse.cz> <20180924200258.GK18685@dhcp22.suse.cz> From: Vlastimil Babka Openpgp: preference=signencrypt Autocrypt: addr=vbabka@suse.cz; prefer-encrypt=mutual; keydata= xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+ 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSFWbGFzdGltaWwg QmFia2EgPHZiYWJrYUBzdXNlLmNvbT7CwZcEEwEKAEECGwMFCwkIBwMFFQoJCAsFFgIDAQAC HgECF4ACGQEWIQSpQNQ0mSwujpkQPVAiT6fnzIKmZAUCWi/zTwUJBbOLuQAKCRAiT6fnzIKm ZIpED/4jRN/6LKZZIT4R2xoou0nJkBGVA3nfb+mUMgi3uwn/zC+o6jjc3ShmP0LQ0cdeuSt/ t2ytstnuARTFVqZT4/IYzZgBsLM8ODFY5vGfPw00tsZMIfFuVPQX3xs0XgLEHw7/1ZCVyJVr mTzYmV3JruwhMdUvIzwoZ/LXjPiEx1MRdUQYHAWwUfsl8lUZeu2QShL3KubR1eH6lUWN2M7t VcokLsnGg4LTajZzZfq2NqCKEQMY3JkAmOu/ooPTrfHCJYMF/5dpi8YF1CkQF/PVbnYbPUuh dRM0m3NzPtn5DdyfFltJ7fobGR039+zoCo6dFF9fPltwcyLlt1gaItfX5yNbOjX3aJSHY2Vc A5T+XAVC2sCwj0lHvgGDz/dTsMM9Ob/6rRJANlJPRWGYk3WVWnbgW8UejCWtn1FkiY/L/4qJ UsqkId8NkkVdVAenCcHQmOGjRQYTpe6Cf4aQ4HGNDeWEm3H8Uq9vmHhXXcPLkxBLRbGDSHyq vUBVaK+dAwAsXn/5PlGxw1cWtur1ep7RDgG3vVQDhIOpAXAg6HULjcbWpBEFaoH720oyGmO5 kV+yHciYO3nPzz/CZJzP5Ki7Q1zqBb/U6gib2at5Ycvews+vTueYO+rOb9sfD8BFTK386LUK uce7E38owtgo/V2GV4LMWqVOy1xtCB6OAUfnGDU2EM7ATQRbGTU1AQgAn0H6UrFiWcovkh6E XVcl+SeqyO6JHOPm+e9Wu0Vw+VIUvXZVUVVQLa1PQDUi6j00ChlcR66g9/V0sPIcSutacPKf dKYOBvzd4rlhL8rfrdEsQw5ApZxrA8kYZVMhFmBRKAa6wos25moTlMKpCWzTH84+WO5+ziCT sTUZASAToz3RdunTD+vQcHj0GqNTPAHK63sfbAB2I0BslZkXkY1RLb/YhuA6E7JyEd2pilZO rIuBGl/5q2qSakgnAVFWFBR/DO27JuAksYnq+aH8vI0xGvwn75KqSk4UzAkDzWSmO4ZHuahK tQgZNsMYV+PGayRBX9b9zbldzopoLBdqHc4njQARAQABwsF8BBgBCgAmFiEEqUDUNJksLo6Z ED1QIk+n58yCpmQFAlsZNTUCGwwFCQPCZwAACgkQIk+n58yCpmQ83g/9Frg1sRMdGPn98zV+ O2eC3h0p5f/oxxQ8MhG5znwHoW4JDG2TuxfcQuz7X7Dd5JWscjlw4VFJ2DD+IrDAGLHwPhCr RyfKalnrbYokvbClM9EuU1oUuh7k+Sg5ECNXEsamW9AiWGCaKWNDdHre3Lf4xl+RJWxghOVW RiUdpLA/a3yDvJNVr6rxkDHQ1P24ZZz/VKDyP+6g8aty2aWEU0YFNjI+rqYZb2OppDx6fdma YnLDcIfDFnkVlDmpznnGCyEqLLyMS3GH52AH13zMT9L9QYgT303+r6QQpKBIxAwn8Jg8dAlV OLhgeHXKr+pOQdFf6iu2sXlUR4MkO/5KWM1K0jFR2ug8Pb3aKOhowVMBT64G0TXhQ/kX4tZ2 ZF0QZLUCHU3Cigvbu4AWWVMNDEOGD/4sn9OoHxm6J04jLUHFUpFKDcjab4NRNWoHLsuLGjve Gdbr2RKO2oJ5qZj81K7os0/5vTAA4qHDP2EETAQcunTn6aPlkUnJ8aw6I1Rwyg7/XsU7gQHF IM/cUMuWWm7OUUPtJeR8loxZiZciU7SMvN1/B9ycPMFs/A6EEzyG+2zKryWry8k7G/pcPrFx O2PkDPy3YmN1RfpIX2HEmnCEFTTCsKgYORangFu/qOcXvM83N+2viXxG4mjLAMiIml1o2lKV cqmP8roqufIAj+Ohhzs= Message-ID: <0aa3eb55-82c0-eba3-b12c-2ba22e052a8e@suse.cz> Date: Mon, 24 Sep 2018 22:43:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180924200258.GK18685@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/24/18 10:02 PM, Michal Hocko wrote: > On Mon 24-09-18 21:56:03, Michal Hocko wrote: >> On Mon 24-09-18 12:30:07, David Rientjes wrote: >>> Commit 1860033237d4 ("mm: make PR_SET_THP_DISABLE immediately active") >>> introduced a regression in that userspace cannot always determine the set >>> of vmas where thp is ineligible. >>> >>> Userspace relies on the "nh" flag being emitted as part of /proc/pid/smaps >>> to determine if a vma is eligible to be backed by hugepages. >> >> I was under impression that nh resp hg flags only tell about the madvise >> status. How do you exactly use these flags in an application? >> >> Your eligible rules as defined here: >> >>> + [*] A process mapping is eligible to be backed by transparent hugepages (thp) >>> + depending on system-wide settings and the mapping itself. See >>> + Documentation/admin-guide/mm/transhuge.rst for default behavior. If a >>> + mapping has a flag of "nh", it is not eligible to be backed by hugepages >>> + in any condition, either because of prctl(PR_SET_THP_DISABLE) or >>> + madvise(MADV_NOHUGEPAGE). PR_SET_THP_DISABLE takes precedence over any >>> + MADV_HUGEPAGE. >> >> doesn't seem to match the reality. I do not see all the file backed >> mappings to be nh marked. So is this really about eligibility rather >> than the madvise status? Maybe it is just the above documentation that >> needs to be updated. Yeah the change from madvise to eligibility in the doc seems to go too far. >> That being said, I do not object to the patch, I am just trying to >> understand what is the intended usage for the flag that does try to say >> more than the madvise status. > > And moreover, how is the PR_SET_THP_DISABLE any different from the > global THP disabled case. Do we want to set all vmas to nh as well? Probably not. It's easy to check the global status, but is it possible to query for the prctl flags of a process? We are looking at process or even vma-specific flags here. If the prctl was historically implemented via VM_NOHUGEPAGE and thus reported as such in smaps, it makes sense to do so even with the MMF_ flag IMHO?