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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D44DC433EF for ; Fri, 29 Oct 2021 07:11:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E23FB61100 for ; Fri, 29 Oct 2021 07:11:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E23FB61100 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 1490E6B0071; Fri, 29 Oct 2021 03:11:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0D3606B0072; Fri, 29 Oct 2021 03:11:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB4DE940007; Fri, 29 Oct 2021 03:11:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0003.hostedemail.com [216.40.44.3]) by kanga.kvack.org (Postfix) with ESMTP id BFC106B0071 for ; Fri, 29 Oct 2021 03:11:27 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 28D4D8249980 for ; Fri, 29 Oct 2021 07:11:27 +0000 (UTC) X-FDA: 78748604214.19.FB25668 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf16.hostedemail.com (Postfix) with ESMTP id EF534F000095 for ; Fri, 29 Oct 2021 07:11:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635491486; 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=LCTTbBJsrfXvFYN8/T5V0SHnU8uYrvusDcCssMFXxdU=; b=S4PoxIo2xiCCO3UAj1bMyYMZwSZJPe9ABQ7m/lSk779bbFWe5q5D3ECY7Igx2CxWj4W/K3 1SYIIq7lFsXwmB71OKWkx5Dln1C0+wIsQEyY5z15IB8v1TBmmk+4N/INn6IXbSdpGtv0ih s9n2XEA6yg1BfEC4Hw8CWOVuqRth8nc= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-331-6vu5H5GAMcOb03NtmcpigA-1; Fri, 29 Oct 2021 03:11:22 -0400 X-MC-Unique: 6vu5H5GAMcOb03NtmcpigA-1 Received: by mail-wr1-f69.google.com with SMTP id d13-20020adfa34d000000b00160aa1cc5f1so3095466wrb.14 for ; Fri, 29 Oct 2021 00:11:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=LCTTbBJsrfXvFYN8/T5V0SHnU8uYrvusDcCssMFXxdU=; b=hFeJV/Z7EAXy1fCZWjGcN2gVsIJF0ly42hI8NO69H80TDYH94q4oWmeEOuOAez8alM CdATEytZtQYsYl6tEGBizxr+oZLSuh9ZoZSn8kyw+YenQsvbyUj24xKzZrKpc/GBENxA uhHag8757v4gIEIuXzqCabFglPvTDRhXHqUehTKuzzXCpMzV3xPAJ7Ue5FGhpQ/CGOrB rCcgLdqpeW+ZA6bqwIV9JWpF8cCZ151TkRIP1Ilr23NAGMZfsFgFARyV9FQ3ria96Y84 kAxaBNaUmEA4/sVK/njdif5pVsSJrTS+Wf3zRhwO+JIKGgHrBuCb2GRcp2LEwq2T4GSn o9Pw== X-Gm-Message-State: AOAM53111JhNRIv8dH6e1pFG9h6VFnrRHkgBqdF2QaC7lWEZy+9OHAoD mSeIJdC9PqzF/bYQmXNCD+VS2KjIFM/LJUm6xKLQMbl/+gu0kj0NhLu8rC9ROBTNhN01y1R8PMN UrL7fxXjkaIg= X-Received: by 2002:a05:6000:1a86:: with SMTP id f6mr12197300wry.343.1635491481597; Fri, 29 Oct 2021 00:11:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxS76O1DPscffsFoErrXA8bL8tphwuCC2AJB6HaGSvmdC6xJu4mAOkmQfN1z+FnFJdOvm5FlA== X-Received: by 2002:a05:6000:1a86:: with SMTP id f6mr12197272wry.343.1635491481393; Fri, 29 Oct 2021 00:11:21 -0700 (PDT) Received: from [192.168.3.132] (p4ff23b86.dip0.t-ipconnect.de. [79.242.59.134]) by smtp.gmail.com with ESMTPSA id v6sm6025294wrx.17.2021.10.29.00.11.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Oct 2021 00:11:21 -0700 (PDT) Message-ID: <2fede4d2-9d82-eac9-002b-9a7246b2c3f8@redhat.com> Date: Fri, 29 Oct 2021 09:11:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 To: Mina Almasry Cc: Yu Zhao , "Paul E . McKenney" , Jonathan Corbet , Andrew Morton , Peter Xu , Ivan Teterevkov , Florian Schmidt , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org References: <20211028205854.830200-1-almasrymina@google.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v1] mm: Add /proc/$PID/pageflags In-Reply-To: <20211028205854.830200-1-almasrymina@google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: EF534F000095 X-Stat-Signature: 8kja35xm5691hty4115k5mnrw5pwiy3s Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=S4PoxIo2; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf16.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1635491480-127075 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 28.10.21 22:58, Mina Almasry wrote: > From: Yu Zhao > > This file lets a userspace process know the page flags of each of its virtual > pages. It contains a 64-bit set of flags for each virtual page, containing > data identical to that emitted by /proc/kpageflags. This allows the user-space > task can learn the kpageflags for the pages backing its address-space by > consulting one file, without needing to be root. > > Example use case is a performance sensitive user-space process querying the > hugepage backing of its own memory without the root access required to access > /proc/kpageflags, and without accessing /proc/self/smaps_rollup which can be > slow and needs to hold mmap_lock. Can you elaborate on a) The target use case. Are you primarily interested to see if a page given base page is head or tail? b) Your mmap_lock comment. pagemap_read() needs to hold the mmap lock in read mode while walking process page tables via walk_page_range(). Also, do you have a rough performance comparison? > > Similar to /proc/kpageflags, the flags printed out by the kernel for > each page are provided by stable_page_flags(), which exports flag bits > that are user visible and stable over time. It exports flags (documented for pageflags_read()) that are not applicable to processes, like OFFLINE. BUDDY, SLAB, PGTABLE ... and can never happen. Some of these kpageflags are not even page->flags, they include abstracted types we use for physical memory pages based on other struct page members (OFFLINE, BUDDY, MMAP, PGTABLE, ...). This feels wrong. Also, to me it feels like we are exposing too much internal information to the user, essentially making it ABI that user space processes will rely on. Did you investigate a) Reducing the flags we expose to a bare minimum necessary for your use case (and actually applicable to mmaped pages). b) Extending pagemap output instead. You seem to be interested in the "hugepage backing", which smells like "what is mapped" as in "pagemap". -- Thanks, David / dhildenb