From: Brian Bloniarz <bmb@athenacr.com>
To: mtk.manpages@gmail.com
Cc: Michael Kerrisk <mtk.manpages@googlemail.com>,
Jens Axboe <jens.axboe@oracle.com>,
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Miklos Szeredi <miklos@szeredi.hu>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] pipe: add support for shrinking and growing pipes
Date: Mon, 24 May 2010 10:51:38 -0400 [thread overview]
Message-ID: <4BFA927A.8070305@athenacr.com> (raw)
In-Reply-To: <AANLkTikwTa16lDh87zkI-L9SaI9jG1_eqZuo4z7dj2qP@mail.gmail.com>
On 05/24/2010 03:28 AM, Michael Kerrisk wrote:
> Actually, SO_*BUF is pretty weird. It returns double what was
> supplied. It's not simply a matter of rounding up: it always doubles
> what was supplied.
Rationale in net/core/sock.c:
set_rcvbuf:
sk->sk_userlocks |= SOCK_RCVBUF_LOCK;
/*
* We double it on the way in to account for
* "struct sk_buff" etc. overhead. Applications
* assume that the SO_RCVBUF setting they make will
* allow that much actual data to be received on that
* socket.
*
* Applications are unaware that "struct sk_buff" and
* other overheads allocate from the receive buffer
* during socket buffer allocation.
*
* And after considering the possible alternatives,
* returning the value we actually used in getsockopt
* is the most desirable behavior.
*/
if ((val * 2) < SOCK_MIN_RCVBUF)
sk->sk_rcvbuf = SOCK_MIN_RCVBUF;
else
sk->sk_rcvbuf = val * 2;
break;
I'm guessing pipes don't have this kind of wrinkle.
next prev parent reply other threads:[~2010-05-24 14:51 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-19 16:45 [patch] pipe: add support for shrinking and growing pipes Miklos Szeredi
2010-05-19 16:49 ` Linus Torvalds
2010-05-19 18:05 ` Jens Axboe
2010-05-19 19:05 ` Jens Axboe
2010-05-20 8:33 ` Miklos Szeredi
2010-05-20 8:37 ` Jens Axboe
2010-05-20 17:42 ` Linus Torvalds
2010-05-20 17:48 ` Jens Axboe
2010-05-21 17:13 ` Rick Sherm
2010-05-23 5:30 ` Michael Kerrisk
2010-05-23 2:38 ` Andrew Morton
2010-05-23 5:52 ` Michael Kerrisk
2010-05-23 7:09 ` Jens Axboe
2010-05-23 9:24 ` Michael Kerrisk
2010-05-23 17:47 ` Jens Axboe
2010-05-24 1:43 ` OGAWA Hirofumi
2010-05-24 4:43 ` Michael Kerrisk
2010-05-24 4:43 ` Michael Kerrisk
2010-05-24 7:05 ` Jens Axboe
2010-05-24 7:27 ` Michael Kerrisk
2010-05-24 7:27 ` Michael Kerrisk
2010-05-24 17:35 ` Jens Axboe
2010-05-24 17:52 ` Michael Kerrisk
2010-05-24 17:56 ` Jens Axboe
2010-05-25 4:01 ` Michael Kerrisk
2010-06-01 7:48 ` Jens Axboe
2010-06-01 15:22 ` Linus Torvalds
2010-06-01 16:36 ` Loke, Chetan
2010-05-27 6:49 ` Michael Kerrisk
2010-06-01 7:45 ` Jens Axboe
2010-06-02 19:25 ` Michael Kerrisk
2010-06-03 6:10 ` Jens Axboe
2010-06-03 6:46 ` Michael Kerrisk
2010-06-03 7:01 ` Jens Axboe
2010-06-03 7:01 ` Jens Axboe
2010-06-03 7:05 ` Michael Kerrisk
2010-06-03 7:05 ` Michael Kerrisk
2010-06-03 7:48 ` Michael Kerrisk
2010-06-03 7:48 ` Michael Kerrisk
2010-06-03 7:58 ` Michael Kerrisk
2010-06-03 7:58 ` Michael Kerrisk
2010-06-03 8:29 ` Michael Kerrisk
2010-06-03 8:53 ` Michael Kerrisk
[not found] ` <4C07862D.4090709@fusionio.com>
[not found] ` <AANLkTincO5thcP-yASUtIV41TtY3ZmG9YSU-J5nT2sFg@mail.gmail.com>
2010-06-03 11:11 ` Jens Axboe
[not found] ` <4C078610.6020901@fusionio.com>
[not found] ` <AANLkTinhO5oRDPXyXaeAOZU3i55eBKsx4iFMOzwm98na@mail.gmail.com>
[not found] ` <AANLkTin_8MU3AbJ_KeXr2uTxtRFJ5ABmBAyigU6m-C6u@mail.gmail.com>
2010-06-03 11:12 ` Jens Axboe
2010-06-03 11:32 ` Miklos Szeredi
2010-06-03 11:37 ` Jens Axboe
2010-06-03 12:45 ` Miklos Szeredi
2010-06-03 12:50 ` Jens Axboe
2010-06-19 5:45 ` Michael Kerrisk
2010-06-19 18:13 ` Jens Axboe
2010-06-20 5:37 ` Michael Kerrisk
2010-06-03 16:06 ` Miklos Szeredi
2010-05-24 7:04 ` Jens Axboe
2010-05-24 7:28 ` Michael Kerrisk
2010-05-24 7:28 ` Michael Kerrisk
2010-05-24 7:49 ` OGAWA Hirofumi
2010-05-24 14:51 ` Brian Bloniarz [this message]
2010-05-24 15:43 ` Michael Kerrisk
2010-05-24 7:46 ` OGAWA Hirofumi
2010-05-24 17:15 ` Jens Axboe
2010-05-24 18:12 ` OGAWA Hirofumi
2010-05-24 18:16 ` Michael Kerrisk
2010-05-20 12:52 ` Andi Kleen
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=4BFA927A.8070305@athenacr.com \
--to=bmb@athenacr.com \
--cc=akpm@linux-foundation.org \
--cc=hirofumi@mail.parknet.co.jp \
--cc=jens.axboe@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mtk.manpages@gmail.com \
--cc=mtk.manpages@googlemail.com \
--cc=torvalds@linux-foundation.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.