From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Davidlohr Bueso <davidlohr@hp.com>,
Manfred Spraul <manfred@colorfullife.com>
Cc: mtk.manpages@gmail.com, akpm@linux-foundation.org, aswin@hp.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] ipc,msg: loosen check for full queue
Date: Fri, 16 May 2014 14:47:20 +0200 [thread overview]
Message-ID: <537608D8.7030000@gmail.com> (raw)
In-Reply-To: <1400168793.6946.10.camel@buesod1.americas.hpqcorp.net>
Hi Davidlohr,
On 05/15/2014 05:46 PM, Davidlohr Bueso wrote:
> On Thu, 2014-05-15 at 06:20 +0200, Manfred Spraul wrote:
>> Hi Davidlohr,
>>
>> On 05/14/2014 09:50 PM, Davidlohr Bueso wrote:
>>> Do you have any preferences? I can cook up a patch if you think that
>>> this merits Linux having MSGTQL.
>> MSGTQL means a global counter - therefore zero scalability. That's why I
>> didn't implement it when I noticed the issue with 0-byte messages.
>
> Hmmm so I was actually thinking of calculating it on demand, but after a
> closer look, we don't track each queue in the system, which would have
> made this rather trivial.
>
> We do however have plenty of similar counters in the kernel, and the
> natural way of dealing with the scalability issue is using percpu
> counters. But I won't argue much if we leave it as it is, it's been like
> that since almost forever and no one is complaining but me.
>
> Andrew, could you please drop this patch from -mm, I'll send another one
> to add a comment instead.
>
>>> Worst case scenario, we should update the msgsnd(2) manpage and document
>>> this unique Linux behavior.
>> I would document the current behavior.
>
> Cc'ing Michael. Here is a vague attempt to update our manpage, feel free
> to update it to your taste.
>
> Thanks,
> Davidlohr
>
> 8<------------------------------------------------------------
> From: Davidlohr Bueso <davidlohr@hp.com>
> Subject: [PATCH] msgop.2: Document full queue criteria
>
> Explicitly mention the two conditions we rely on when
> checking if a message queue is full when calling msgsnd(2).
>
> Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
> ---
> man2/msgop.2 | 22 +++++++++++++++++++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/man2/msgop.2 b/man2/msgop.2
> index 3f5bc36..b4c8c04 100644
> --- a/man2/msgop.2
> +++ b/man2/msgop.2
> @@ -105,13 +105,29 @@ by
> If sufficient space is available in the queue,
> .BR msgsnd ()
> succeeds immediately.
> -(The queue capacity is defined by the
> -.I msg_qbytes
> +The queue capacity is governed by the
> +.I msg_qbytes
> field in the associated data structure for the message queue.
> During queue creation this field is initialized to
> .B MSGMNB
> bytes, but this limit can be modified using
> -.BR msgctl (2).)
> +.BR msgctl (2).
> +A full queue is defined by two factors :
> +.IP * 2
> +The new msg size + current size of the queue is greater than the
> +queue's maximum size (the
> +.I msg_qbytes
> +field).
> +.IP *
> +The current amount of messages in the queue + 1 (the new msg) is
> +greater than the queue's maximum size (the
> +.I msg_qbytes
> +field). This is necessary to prevent users from using infinite
> +amounts of locked memory (used by the kernel for headers) by
> +sending 0-byte messages. This is equivalent to the traditional
> +MSGTQL parameter present in many Unix systems. This behavior
> +is unique to Linux.
> +.PP
> If insufficient space is available in the queue, then the default
> behavior of
> .BR msgsnd ()
I applied, and reworded a little. Also: I dropped the piece about
MSGTQL, since it is not quite right. As noted elsewhere on the page
MSGTQL is a *system-wide* (not per-queue) limit on the number of
messages in all MQs. Also: I dropped the piece saying this is unique
to Linux. I believe that's true, but it implies there's a lot
more standardization around these limits than there actually is
in my observation.
Thanks for the patch!
Cheers,
Michael
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
next prev parent reply other threads:[~2014-05-16 17:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-13 20:27 [PATCH -next 0/5] ipc,msg: fixes and updates Davidlohr Bueso
2014-05-13 20:27 ` [PATCH 1/5] ipc,msg: use current->state helpers Davidlohr Bueso
2014-05-17 17:55 ` Manfred Spraul
2014-05-13 20:27 ` [PATCH 2/5] ipc,msg: move some msgq ns code around Davidlohr Bueso
2014-05-17 17:57 ` Manfred Spraul
2014-05-13 20:27 ` [PATCH 3/5] ipc,msg: always respect MSG_NOERROR Davidlohr Bueso
2014-05-18 5:53 ` Manfred Spraul
2014-05-18 18:01 ` Davidlohr Bueso
2014-05-19 18:01 ` Manfred Spraul
2014-05-13 20:27 ` [PATCH 4/5] ipc,msg: document volatile r_msg Davidlohr Bueso
2014-05-18 6:08 ` Manfred Spraul
2014-05-13 20:27 ` [PATCH 5/5] ipc,msg: loosen check for full queue Davidlohr Bueso
2014-05-14 18:00 ` Manfred Spraul
2014-05-14 19:50 ` Davidlohr Bueso
2014-05-15 4:20 ` Manfred Spraul
2014-05-15 15:46 ` Davidlohr Bueso
2014-05-16 12:47 ` Michael Kerrisk (man-pages) [this message]
2014-05-18 18:16 ` Davidlohr Bueso
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=537608D8.7030000@gmail.com \
--to=mtk.manpages@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aswin@hp.com \
--cc=davidlohr@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).