On Fri, 2014-05-16 at 14:47 +0200, Michael Kerrisk (man-pages) wrote: > 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 <davidl...@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 <davidl...@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!
Looks good, thanks Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
