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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2D569C46467 for ; Wed, 11 Jan 2023 18:00:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A35178E0002; Wed, 11 Jan 2023 13:00:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E3AB8E0001; Wed, 11 Jan 2023 13:00:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8AB9F8E0002; Wed, 11 Jan 2023 13:00:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7B6CD8E0001 for ; Wed, 11 Jan 2023 13:00:30 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 29C391A08AA for ; Wed, 11 Jan 2023 18:00:30 +0000 (UTC) X-FDA: 80343283020.09.7897EE3 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf12.hostedemail.com (Postfix) with ESMTP id 4700640015 for ; Wed, 11 Jan 2023 18:00:27 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Z2VFQQvS; spf=pass (imf12.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673460027; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=st+rBfXe657tktuM+VC62FoufdfMZ6foNZG+N8Yy0J4=; b=vudsYDpb664MzY7jm9q9rYnU4/Wh31xYVXABuMEIoPCP83DFo861ET7me05k5QNNROaW9s B+q2tIKWMBSKu6u6fdYcKqBxV0iXd/mjVcEhtqfLnqPTaBscst3rk+zGblR6nO2C2YY5EW M2+QYl6tyCexRuPOCEjGcWg6gDV+0SI= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Z2VFQQvS; spf=pass (imf12.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673460027; a=rsa-sha256; cv=none; b=u9Pc1uZh1Eltvzs+Oul8MmFCw+y5vrJ+HEA1pMeVV24w13TZ2NePrVoSpLYtmiwZRcRAJ0 X9KpxdlAsa8Tp1xyU++EMmiCE+U+gDcWw1PEKm2gxA+1k2cGORabPNYIsCBaFq+KOWsZUg ebbR8fbidEMO8A+rECI7fEqd4nrp9vE= Received: by mail-wm1-f43.google.com with SMTP id c4-20020a1c3504000000b003d9e2f72093so10160812wma.1 for ; Wed, 11 Jan 2023 10:00:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=st+rBfXe657tktuM+VC62FoufdfMZ6foNZG+N8Yy0J4=; b=Z2VFQQvScbNOgpYADSIjXCaR031NtVBvEhLSqtA1ZWt1AYcUONDha6jpfpwQejZeFG Scj3GxKPZKJYColGxugCLFRnl4mwOqe1Vijvnotfs41GlUo9ClpK4vH9P3ql9J//bYo9 nHnfgE/qdbUYLVMkQN47Q0S2UgntwmN0tn8iGbM78Egrfq7WbH1HGw4+7xXefu4u25xA vqd76h2vsw0Z5Zpt77Ijx57KeVSU7jH4jhXvgWYfDTWIeTosPeZ+jzW74mfVXhCqASTS 4fpQHfn6EfRBGHSB+1w135Dvf2JK4X4I4NWoaoZqkd6+TXuYIbudXCfT2D44P3pGpAMV xUKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=st+rBfXe657tktuM+VC62FoufdfMZ6foNZG+N8Yy0J4=; b=TDy2BZaKE0uf5DJmFORau2rFC9v/NCbLboj+td2SDzS1AaDkyIoREoMGCC7OxLaQul 6fKDcG+rOoeEu1Dj2F9alIjm69egaznkO1oTCAnPSOClIu+cLC8RY7bT/Z/aNngDc5W7 XJMX3hySxJhB0O6tlKlo4lNp6goUaMZNeb7Y3e89Wox+VQgogItx64dr8jpy7djC/Y8i YX7SxQ26GGkfO0tLoJCYnjkDMRCc1ex8fshozWd2bTzgTOZ9DuxFcmqjhkvUsHq5kJIP QWupGSKZr/yNW42VDge8DnDzDDpHWKPmrPlML0BPxBONRBUmCduQnyw4NxI/zPB4JY+9 UaXA== X-Gm-Message-State: AFqh2kp/EQnPd4iqdszCcPoy0Np5ZaWAd6KZXd/QKnwjHpZLfsA8rffZ j9K43tOXUEy2ODrf9staeg03ewJ75VCnCUkM0ak= X-Google-Smtp-Source: AMrXdXu4ANeLrh0mXoN96h38xoOI20kDaWI2yGU5iz/RkxOKrLUUP0joFd8pz/CIRKVE+9pTwQiD3W29jq3fb7iTksg= X-Received: by 2002:a05:600c:1c90:b0:3d2:1d51:2476 with SMTP id k16-20020a05600c1c9000b003d21d512476mr3468587wms.77.1673460025717; Wed, 11 Jan 2023 10:00:25 -0800 (PST) MIME-Version: 1.0 References: <20221216192149.3902877-1-nphamcs@gmail.com> <20221216192149.3902877-4-nphamcs@gmail.com> <20221216134814.61c8d5119ceb4179c68e1cd7@linux-foundation.org> In-Reply-To: From: Nhat Pham Date: Wed, 11 Jan 2023 10:00:14 -0800 Message-ID: Subject: Re: [PATCH v4 3/4] cachestat: implement cachestat syscall To: Andrew Morton Cc: hannes@cmpxchg.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, bfoster@redhat.com, willy@infradead.org, kernel-team@meta.com Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: nqfkdxpukp79spzter1soz831mabxpk5 X-Rspam-User: X-Rspamd-Queue-Id: 4700640015 X-Rspamd-Server: rspam06 X-HE-Tag: 1673460027-640553 X-HE-Meta: U2FsdGVkX18axEs70V1ELe3NgXNJ/u/IUD+lTOMWnKTq3N1SgZY0boIzTjwooRuZo+ixb91ANJ6BGTcvDBjSZZhyGAmXwGgFHWa1172ZHrj83ap6XTybxzjmcmS5bm7AGmgB5ERxB1RD3VzdOM+tV04RDaFTROcxtCYvyEinie9Hj49K/Zn723ct32WKkwrsz+eQCqRMR2Xg02UzxWRq615O0PZBRb+9A1AYd45i6L0CHrOiW8XfJMXG6vBUfyNhYLvcQFRAHZXMk1s6fUgZHYvua0LvaCxkziJssQqKgEj5KyGffSfEJq116OF/dMeLOtZByZPuvVZpWcjGUkS6N1PFJl8+c1YJewVVKUZq4rvJwpo7QqG8YT19N7Jn81JRyiPcN+T0WblAF91VFAE0dXSyYMTywDEXde/wNLB4YekTSemS47RBJsiesDvcJQ3+HbGjdK+pcOii37aN/Ouj/YC0mdMlTAhJ4x5yYEKi/XpiHUmMimb9heZApNGaK6U48joncSAX3IXDibt7YR7xh2pli0IJARu+WChtNrCZDUDAwN45pXAl0qfVYLlWwAnM7I7Uq+FagFYnMbQEDWlYLQIqHhOwMyNz+Kf7e4jpOim4y0m0hpiub2GBjGOrpshiRY5P0bA5lgAjEy/BFQ8bKVPeWDRS7GjxN6/L5QghNJVIFklSMOOSK6mD1TLgVBtB+Jz/qClq4815qpJlti/gGmYnC4pQf/38mPuwpBZWKEqY4gRob1zg73CNRnJXZuk4YmG7MWW7GJQSUvHyKLO8N1IQK0vOEuwxpvVS7YPUsrpYKyoZCyPp+gr8W2Ch+X09BkCcG4Jw3qkmFbL34O0u5bHjrcAcYtrCWcwC6VF+DeI3W9TJkMxb8yr8Nzmzf6vHNfbIaPJO9YZ5L8NRJ/yl3S6ZW9t3xt0T0OQ9DQ8ItGlW2UrG7ctYuUtT2uKUnTwvBC3ruM7+8by5RLXVV/v R4lg8at2 mQ8Sm141SGtxAYlcVKANfuZUHCV0TcZKKXzPjWhPe0SI+gl3ySgaGPktz1g== 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, Dec 21, 2022 at 4:37 PM Nhat Pham wrote: > > On Fri, Dec 16, 2022 at 1:48 PM Andrew Morton wrote: > > > > On Fri, 16 Dec 2022 11:21:48 -0800 Nhat Pham wrote: > > > > > Implement a new syscall that queries cache state of a file and > > > summarizes the number of cached pages, number of dirty pages, number of > > > pages marked for writeback, number of (recently) evicted pages, etc. in > > > a given range. > > > > > > NAME > > > cachestat - query the page cache status of a file. > > > > > > SYNOPSIS > > > #include > > > > > > struct cachestat { > > > __u64 nr_cache; > > > __u64 nr_dirty; > > > __u64 nr_writeback; > > > __u64 nr_evicted; > > > __u64 nr_recently_evicted; > > > }; > > > > > > int cachestat(unsigned int fd, off_t off, size_t len, > > > size_t cstat_size, struct cachestat *cstat, > > > unsigned int flags); > > > > > > DESCRIPTION > > > cachestat() queries the number of cached pages, number of dirty > > > pages, number of pages marked for writeback, number of (recently) > > > evicted pages, in the bytes range given by `off` and `len`. > > > > I suggest this be spelled out better: "number of evicted and number or > > recently evicted pages". > > > > I suggest this clearly tell readers what an "evicted" page is - they > > aren't kernel programmers! > > Valid points - I'll try to explain this more clearly in the future > versions of this patch series, especially in the draft man page. > > > > > What is the benefit of the "recently evicted" pages? "recently" seems > > very vague - what use is this to anyone? > > This eviction recency semantics comes from the LRU's refault > computation. Users of cachestat might be interested in two very > different questions: > > 1. How many pages are not resident in the page cache. > 2. How many pages are recently evicted (recently enough that > their refault will be construed as memory pressure). > > The first question is answered with nr_evicted, whereas the second > is answered with nr_recently_evicted. > > I will figure out a way to explain this better in the next version. Users > definitely do not need to know the nitty gritty details of LRU logic, > but they should know the general idea of each field at least. > > > > > > These values are returned in a cachestat struct, whose address is > > > given by the `cstat` argument. > > > > > > The `off` and `len` arguments must be non-negative integers. If > > > `len` > 0, the queried range is [`off`, `off` + `len`]. If `len` == > > > 0, we will query in the range from `off` to the end of the file. > > > > > > `cstat_size` allows users to obtain partial results. The syscall > > > will copy the first `csstat_size` bytes to the specified userspace > > > memory. `cstat_size` must be a non-negative value that is no larger > > > than the current size of the cachestat struct. > > > > > > The `flags` argument is unused for now, but is included for future > > > extensibility. User should pass 0 (i.e no flag specified). > > > > Why is `flags' here? We could add an unused flags arg to any syscall, > > but we don't. What's the plan? > > I included this field to ensure that cachestat can be extended safely, > especially when different users might want different things out of it. > > For instance, in the future there might be new fields/computations > that are too heavy for certain use cases - a flag could be used to > disable/skip such fields/computations. > > Another thing it might be used for is the huge page counting - > we have not implemented this in this version yet, but it might > introduce murky semantics to new/existing fields in struct > cachestat. Or maybe not - but worst case scenario we can > leave this decision to the users to decide through flags. > > I'm sure there are more potential pitfalls that the flags could > save us from, but these are the two on top of my head. > > > > > Are there security implications? If I know that some process has a > > file open, I can use cachestat() to infer which parts of that file > > they're looking at (like mincore(), I guess). And I can infer which > > parts they're writing to, unlike mincore(). > > This one, I'm not 100% sure, but it is a valid concern. Let me think > about it and discuss with more security-oriented minds before > responding to this. Hmm I've given it some more thought. The syscall does not seem to expose any extra security issue, given that the user already has read permission to the file itself (since they have an fd to that file). This means that the user can already know the underlying data in its entirety, which seems like much more information (and as a result, security risk) than the cache status itself. Do you have something concrete in mind that I might have missed? > > > > > I suggest the [patch 1/4] fixup be separated from this series. > > Sounds good! I'll loop Johannes in about this breakup as well.