All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vegard Nossum <vegard.nossum@oracle.com>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Willy Tarreau <w@1wt.eu>,
	socketpair@gmail.com,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	Jens Axboe <axboe@fb.com>, Al Viro <viro@zeniv.linux.org.uk>,
	linux-api@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 7/8] pipe: make account_pipe_buffers() return a value, and use it
Date: Fri, 19 Aug 2016 11:36:03 +0200	[thread overview]
Message-ID: <57B6D303.2060301@oracle.com> (raw)
In-Reply-To: <676aa52b-c4fc-3bf1-8051-39deca8bf0ab@gmail.com>

On 08/19/2016 07:25 AM, Michael Kerrisk (man-pages) wrote:
> This is an optional patch, to provide a small performance improvement.
> Alter account_pipe_buffers() so that it returns the new value in
> user->pipe_bufs. This means that we can refactor too_many_pipe_buffers_soft()
> and too_many_pipe_buffers_hard() to avoid the costs of repeated use of
> atomic_long_read() to get the value user->pipe_bufs.
[...]
> @@ -627,17 +625,18 @@ struct pipe_inode_info *alloc_pipe_info(void)
>   	struct pipe_inode_info *pipe;
>   	unsigned long pipe_bufs = PIPE_DEF_BUFFERS;
>   	struct user_struct *user = get_current_user();
> +	unsigned long num_bufs;

Maybe user_bufs would be more descriptive since num_bufs is a bit
ambiguous without the context.

>
>   	pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL_ACCOUNT);
>   	if (pipe == NULL)
>   		goto out_free_uid;
>
> -	if (too_many_pipe_buffers_soft(user))
> +	if (too_many_pipe_buffers_soft(atomic_long_read(&user->pipe_bufs)))
>   		pipe_bufs = 1;
>
> -	account_pipe_buffers(user, 0, pipe_bufs);
> +	num_bufs = account_pipe_buffers(user, 0, pipe_bufs);
>
> -	if (too_many_pipe_buffers_hard(user))
> +	if (too_many_pipe_buffers_hard(num_bufs))
>   		goto out_revert_acct;
>
>   	pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer),

Why not structure it like this?

num_bufs = account_pipe_buffers(user, 0, pipe_bufs);
if (too_many_pipe_buffers_soft(num_bufs)) {
	num_bufs = account_pipe_buffers(user, pipe_bufs, 1);
	pipe_bufs = 1;
}
if (too_many_pipe_buffers_hard(num_bufs))
	goto out_revert_acct;

Otherwise you still have the case that somebody makes it past
too_many_pipe_buffers_soft() before the accounting is done.


Vegard

WARNING: multiple messages have this Message-ID (diff)
From: Vegard Nossum <vegard.nossum-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
To: "Michael Kerrisk (man-pages)"
	<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Cc: Willy Tarreau <w@1wt.eu>,
	socketpair-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	Tetsuo Handa
	<penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>,
	Jens Axboe <axboe-b10kYP2dOMg@public.gmane.org>,
	Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 7/8] pipe: make account_pipe_buffers() return a value, and use it
Date: Fri, 19 Aug 2016 11:36:03 +0200	[thread overview]
Message-ID: <57B6D303.2060301@oracle.com> (raw)
In-Reply-To: <676aa52b-c4fc-3bf1-8051-39deca8bf0ab-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On 08/19/2016 07:25 AM, Michael Kerrisk (man-pages) wrote:
> This is an optional patch, to provide a small performance improvement.
> Alter account_pipe_buffers() so that it returns the new value in
> user->pipe_bufs. This means that we can refactor too_many_pipe_buffers_soft()
> and too_many_pipe_buffers_hard() to avoid the costs of repeated use of
> atomic_long_read() to get the value user->pipe_bufs.
[...]
> @@ -627,17 +625,18 @@ struct pipe_inode_info *alloc_pipe_info(void)
>   	struct pipe_inode_info *pipe;
>   	unsigned long pipe_bufs = PIPE_DEF_BUFFERS;
>   	struct user_struct *user = get_current_user();
> +	unsigned long num_bufs;

Maybe user_bufs would be more descriptive since num_bufs is a bit
ambiguous without the context.

>
>   	pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL_ACCOUNT);
>   	if (pipe == NULL)
>   		goto out_free_uid;
>
> -	if (too_many_pipe_buffers_soft(user))
> +	if (too_many_pipe_buffers_soft(atomic_long_read(&user->pipe_bufs)))
>   		pipe_bufs = 1;
>
> -	account_pipe_buffers(user, 0, pipe_bufs);
> +	num_bufs = account_pipe_buffers(user, 0, pipe_bufs);
>
> -	if (too_many_pipe_buffers_hard(user))
> +	if (too_many_pipe_buffers_hard(num_bufs))
>   		goto out_revert_acct;
>
>   	pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer),

Why not structure it like this?

num_bufs = account_pipe_buffers(user, 0, pipe_bufs);
if (too_many_pipe_buffers_soft(num_bufs)) {
	num_bufs = account_pipe_buffers(user, pipe_bufs, 1);
	pipe_bufs = 1;
}
if (too_many_pipe_buffers_hard(num_bufs))
	goto out_revert_acct;

Otherwise you still have the case that somebody makes it past
too_many_pipe_buffers_soft() before the accounting is done.


Vegard

  reply	other threads:[~2016-08-19  9:36 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <67ce15aa-cf43-0c89-d079-2d966177c56d@gmail.com>
2016-08-19  5:25 ` [PATCH 1/8] pipe: relocate round_pipe_size() above pipe_set_size() Michael Kerrisk (man-pages)
2016-08-19  5:25 ` [PATCH 2/8] pipe: move limit checking logic into pipe_set_size() Michael Kerrisk (man-pages)
2016-08-19  5:25   ` Michael Kerrisk (man-pages)
2016-08-19  5:25 ` [PATCH 3/8] pipe: refactor argument for account_pipe_buffers() Michael Kerrisk (man-pages)
2016-08-19  5:25 ` [PATCH 4/8] pipe: fix limit checking in pipe_set_size() Michael Kerrisk (man-pages)
2016-08-19  5:48   ` Willy Tarreau
2016-08-19  5:48     ` Willy Tarreau
2016-08-19 20:51     ` Michael Kerrisk (man-pages)
2016-08-19 20:51       ` Michael Kerrisk (man-pages)
2016-08-21 21:15     ` Michael Kerrisk (man-pages)
2016-08-21 21:15       ` Michael Kerrisk (man-pages)
2016-08-21 21:35       ` Willy Tarreau
2016-08-22 19:37         ` Michael Kerrisk (man-pages)
2016-08-22 19:37           ` Michael Kerrisk (man-pages)
2016-08-19  8:30   ` Vegard Nossum
2016-08-19  8:30     ` Vegard Nossum
2016-08-19 20:56     ` Michael Kerrisk (man-pages)
2016-08-19 20:56       ` Michael Kerrisk (man-pages)
2016-08-19 23:17       ` Michael Kerrisk (man-pages)
2016-08-19 23:17         ` Michael Kerrisk (man-pages)
2016-08-21 10:33         ` Vegard Nossum
2016-08-21 10:33           ` Vegard Nossum
2016-08-21 21:14           ` Michael Kerrisk (man-pages)
2016-08-21 21:14             ` Michael Kerrisk (man-pages)
2016-08-19  5:25 ` [PATCH 5/8] pipe: simplify logic in alloc_pipe_info() Michael Kerrisk (man-pages)
2016-08-19  5:25 ` [PATCH 6/8] pipe: fix limit checking " Michael Kerrisk (man-pages)
2016-08-19  5:25   ` Michael Kerrisk (man-pages)
2016-08-19  5:25 ` [PATCH 7/8] pipe: make account_pipe_buffers() return a value, and use it Michael Kerrisk (man-pages)
2016-08-19  9:36   ` Vegard Nossum [this message]
2016-08-19  9:36     ` Vegard Nossum
2016-08-19 20:51     ` Michael Kerrisk (man-pages)
2016-08-19  5:26 ` [PATCH 8/8] pipe: cap initial pipe capacity according to pipe-max-size limit Michael Kerrisk (man-pages)

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=57B6D303.2060301@oracle.com \
    --to=vegard.nossum@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@fb.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=socketpair@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=w@1wt.eu \
    /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.