Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp5293539rwi; Mon, 17 Oct 2022 19:02:34 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7FL27CooGUvh4Ubuqvzd3ZbRWRlL7VoCpdIkiOl8IAxBBSV/GCaxZ0Um1idATi2JymbD1c X-Received: by 2002:a05:6402:414f:b0:456:c2c1:23ec with SMTP id x15-20020a056402414f00b00456c2c123ecmr503629eda.420.1666058554448; Mon, 17 Oct 2022 19:02:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666058554; cv=none; d=google.com; s=arc-20160816; b=Q1OYCYctJYrZ+UDX8vKZ8PMHnhTjKN+bO849+T21NtXVuajkfUJ66RCjQ/+gGLTmNW dv11G7xdqpYk1EITkG2IGPLUYS5V6dI1olSyoMvNf/65+uJY5k8HuUcH5J0lTVo5gn2A KSWzP1UBJsCzVTm+MI5FGj/xttELW4GrSbSuwLcy8y/9TaL+rjBlwENyut9Pf6ajsK4J CdqvT3iO8wfMRStOo7ap08LUgihviy/enaIiPyd41/9qfo9WPA1wyByK5frYfsrcbR0I UKVm3bW5g8UC8S0VGp7bpLtXFDhrSx6raxKd2LvjxvmNg84PUJ5KWUrZPeWPtxH0OHm0 P1zA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=KRBcOttCmiDjHkWnnifw0I7j48/2zHeIub0jtFD77ZU=; b=svnbYt4yDvff8xqsLLATxVBiC/WOICt2+d7G5RUBYTYu33XJ+AH5BbN/T+MytX5lyL EqRpJyen4FJ1RlKAVu+LNamFEQolo4k/ub/ZQAocCnpVadFK9UdDIuIcp8xdya1azK6L rwV93QF3UYeDvP9ztC/5xzWak4sw9f2ufLaOn7k7SwLCzeotp4aF3R820vKTB20GY7iB qwxiU4U++vv+UszPQDtlkLu3DTHJUPYx2YEKa6Vd2AcsSQAi6FxXQLf3g38vN0EBv+nu RqfwyeiySStJ7oMom5qmH4H24FiYvkrthOQJtb9ZV0stFdoZIXMlbkvJ7o30jHNV7kD3 ciqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=m6PzhQDK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ht22-20020a170907609600b0078de8d119d5si11220698ejc.899.2022.10.17.19.02.08; Mon, 17 Oct 2022 19:02:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=m6PzhQDK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230136AbiJRBrE (ORCPT + 99 others); Mon, 17 Oct 2022 21:47:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229574AbiJRBrD (ORCPT ); Mon, 17 Oct 2022 21:47:03 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D14C267D; Mon, 17 Oct 2022 18:47:02 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 058FF61350; Tue, 18 Oct 2022 01:47:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4618C433D7; Tue, 18 Oct 2022 01:47:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1666057621; bh=GSwzMI+fxz7A5+Z7H3gcMHBja9DcnY/xhhumYR74sI4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=m6PzhQDK6dZDJ4Va7ieuzZ9iN36l/0IFs2IuMVX20Qc1MH++e9+NkouxG+oMEX3Fo 3XeWg3Z3/CLP85cvgIPUEt+Wr/bxxy/mUtGLIMQOri0RB2Ot+nrHPx0G2UGzg/hX1e UEp6T3pyyTeVSuF2bPyU7zK0r+PxthpyOi5tGMr8= Date: Mon, 17 Oct 2022 18:47:00 -0700 From: Andrew Morton To: Ivan Babrou Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@cloudflare.com, Alexey Dobriyan , Al Viro , "Theodore Ts'o" , David Laight , Jonathan Corbet , David Hildenbrand , Johannes Weiner , Christoph Anton Mitterer , Mike Rapoport , Paul Gortmaker , Kalesh Singh Subject: Re: [PATCH v2] proc: report open files as size in stat() for /proc/pid/fd Message-Id: <20221017184700.e1e6944e743bfc38e9abd953@linux-foundation.org> In-Reply-To: <20220922224027.59266-1-ivan@cloudflare.com> References: <20220922224027.59266-1-ivan@cloudflare.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 22 Sep 2022 15:40:26 -0700 Ivan Babrou wrote: > Many monitoring tools include open file count as a metric. Currently > the only way to get this number is to enumerate the files in /proc/pid/fd. > > The problem with the current approach is that it does many things people > generally don't care about when they need one number for a metric. > In our tests for cadvisor, which reports open file counts per cgroup, > we observed that reading the number of open files is slow. Out of 35.23% > of CPU time spent in `proc_readfd_common`, we see 29.43% spent in > `proc_fill_cache`, which is responsible for filling dentry info. > Some of this extra time is spinlock contention, but it's a contention > for the lock we don't want to take to begin with. > > We considered putting the number of open files in /proc/pid/status. > Unfortunately, counting the number of fds involves iterating the open_files > bitmap, which has a linear complexity in proportion with the number > of open files (bitmap slots really, but it's close). We don't want > to make /proc/pid/status any slower, so instead we put this info > in /proc/pid/fd as a size member of the stat syscall result. That sounds awfully logical. > Previously the reported number was zero, so there's very little > risk of breaking anything, while still providing a somewhat logical > way to count the open files with a fallback if it's zero. > > RFC for this patch included iterating open fds under RCU. Thanks > to Frank Hofmann for the suggestion to use the bitmap instead. > > Previously: > > ``` > $ sudo stat /proc/1/fd | head -n2 > File: /proc/1/fd > Size: 0 Blocks: 0 IO Block: 1024 directory > ``` > > With this patch: > > ``` > $ sudo stat /proc/1/fd | head -n2 > File: /proc/1/fd > Size: 65 Blocks: 0 IO Block: 1024 directory > ``` > > Correctness check: > > ``` > $ sudo ls /proc/1/fd | wc -l > 65 > ``` > > I added the docs for /proc//fd while I'm at it. > Dang that's a good changelog. > index e7aafc82be99..394548d26187 100644 > --- a/Documentation/filesystems/proc.rst > +++ b/Documentation/filesystems/proc.rst > @@ -47,6 +47,7 @@ fixes/update part 1.1 Stefani Seibold June 9 2009 > 3.10 /proc//timerslack_ns - Task timerslack value > 3.11 /proc//patch_state - Livepatch patch operation state > 3.12 /proc//arch_status - Task architecture specific information > + 3.13 /proc//fd - List of symlinks to open files > > 4 Configuring procfs > 4.1 Mount options > @@ -2145,6 +2146,22 @@ AVX512_elapsed_ms > the task is unlikely an AVX512 user, but depends on the workload and the > scheduling scenario, it also could be a false negative mentioned above. > > +3.13 /proc//fd - List of symlinks to open files > +------------------------------------------------------- > +This directory contains symbolic links which represent open files > +the process is maintaining. Example output:: > + > + lr-x------ 1 root root 64 Sep 20 17:53 0 -> /dev/null > + l-wx------ 1 root root 64 Sep 20 17:53 1 -> /dev/null > + lrwx------ 1 root root 64 Sep 20 17:53 10 -> 'socket:[12539]' > + lrwx------ 1 root root 64 Sep 20 17:53 11 -> 'socket:[12540]' > + lrwx------ 1 root root 64 Sep 20 17:53 12 -> 'socket:[12542]' > + > +The number of open files for the process is stored in 'size' member > +of stat() output for /proc//fd for fast access. > +------------------------------------------------------- > + > + > Chapter 4: Configuring procfs > ============================= > > diff --git a/fs/proc/fd.c b/fs/proc/fd.c > index 913bef0d2a36..ff526dfc5faa 100644 > --- a/fs/proc/fd.c > +++ b/fs/proc/fd.c > @@ -279,6 +279,34 @@ static int proc_readfd_common(struct file *file, struct dir_context *ctx, > return 0; > } > > +static int proc_readfd_count(struct inode *inode) > +{ > + struct task_struct *p = get_proc_task(inode); > + struct fdtable *fdt; > + unsigned int i, size, open_fds = 0; > + > + if (!p) > + return -ENOENT; > + > + task_lock(p); > + if (p->files) { > + rcu_read_lock(); > + > + fdt = files_fdtable(p->files); > + size = fdt->max_fds; > + > + for (i = size / BITS_PER_LONG; i > 0;) > + open_fds += hweight64(fdt->open_fds[--i]); Could BITMAP_WEIGHT() or __bitmap_weight() or bitmap_weight() be used here? > + rcu_read_unlock(); > + } > + task_unlock(p); > + > + put_task_struct(p); > + > + return open_fds; > +} > + > static int proc_readfd(struct file *file, struct dir_context *ctx) > { > return proc_readfd_common(file, ctx, proc_fd_instantiate); > @@ -319,9 +347,25 @@ int proc_fd_permission(struct user_namespace *mnt_userns, > return rv; > } > > +static int proc_fd_getattr(struct user_namespace *mnt_userns, > + const struct path *path, struct kstat *stat, > + u32 request_mask, unsigned int query_flags) > +{ > + struct inode *inode = d_inode(path->dentry); > + > + generic_fillattr(&init_user_ns, inode, stat); > + > + /* If it's a directory, put the number of open fds there */ > + if (S_ISDIR(inode->i_mode)) > + stat->size = proc_readfd_count(inode); > + > + return 0; > +} > + > const struct inode_operations proc_fd_inode_operations = { > .lookup = proc_lookupfd, > .permission = proc_fd_permission, > + .getattr = proc_fd_getattr, > .setattr = proc_setattr, > }; > > -- > 2.37.2