All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Alexey Dobriyan <adobriyan@gmail.com>, akpm@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v3] proc: faster open/read/close with "permanent" files
Date: Sat, 22 Feb 2020 12:39:39 -0800	[thread overview]
Message-ID: <7c30fd26941948fa1aedd1e73bdc2ebb8efec477.camel@perches.com> (raw)
In-Reply-To: <20200222201539.GA22576@avx2>

On Sat, 2020-02-22 at 23:15 +0300, Alexey Dobriyan wrote:
> Now that "struct proc_ops" exist we can start putting there stuff which
> could not fly with VFS "struct file_operations"...
> 
> Most of fs/proc/inode.c file is dedicated to make open/read/.../close reliable
> in the event of disappearing /proc entries which usually happens if module is
> getting removed. Files like /proc/cpuinfo which never disappear simply do not
> need such protection.
> 
> Save 2 atomic ops, 1 allocation, 1 free per open/read/close sequence for such
> "permanent" files.
> 
> Enable "permanent" flag for
> 
> 	/proc/cpuinfo
> 	/proc/kmsg
> 	/proc/modules
> 	/proc/slabinfo
> 	/proc/stat
> 	/proc/sysvipc/*
> 	/proc/swaps
> 
> More will come once I figure out foolproof way to prevent out module
> authors from marking their stuff "permanent" for performance reasons
> when it is not.
> 
> This should help with scalability: benchmark is "read /proc/cpuinfo R times
> by N threads scattered over the system".

Is this an actual expected use-case?
Is there some additional unnecessary memory consumption
in the unscaled systems?

And trivia:

>  static loff_t proc_reg_llseek(struct file *file, loff_t offset, int whence)
>  {
[]
> +	if (pde_is_permanent(pde)) {
> +		return pde_lseek(pde, file, offset, whence);
> +	} else if (use_pde(pde)) {
> +		rv = pde_lseek(pde, file, offset, whence);
>  		unuse_pde(pde);
>  	}
>  	return rv;
>  }
[]
>  static ssize_t proc_reg_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
>  {
>  	struct proc_dir_entry *pde = PDE(file_inode(file));
>  	ssize_t rv = -EIO;
> -	if (use_pde(pde)) {
> -		typeof_member(struct proc_ops, proc_read) read;
>  
> -		read = pde->proc_ops->proc_read;
> -		if (read)
> -			rv = read(file, buf, count, ppos);
> +	if (pde_is_permanent(pde)) {
> +		return pde_read(pde, file, buf, count, ppos);
> +	} else if (use_pde(pde)) {
> +		rv = pde_read(pde, file, buf, count, ppos);
>  		unuse_pde(pde);

Perhaps all the function call duplication could be minimized
by using code without direct returns like:

	rv = pde_read(pde, file, buf, count, pos);
	if (!pde_is_permanent(pde))
		unuse_pde(pde);

	return rv;



  reply	other threads:[~2020-02-22 20:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-22 20:15 [PATCH v3] proc: faster open/read/close with "permanent" files Alexey Dobriyan
2020-02-22 20:39 ` Joe Perches [this message]
2020-02-23 11:30   ` Alexey Dobriyan
2020-02-24  2:48     ` Joe Perches
2020-02-24 17:55       ` Alexey Dobriyan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7c30fd26941948fa1aedd1e73bdc2ebb8efec477.camel@perches.com \
    --to=joe@perches.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.