All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manfred Spraul <manfred@colorfullife.com>
To: Davidlohr Bueso <davidlohr@hp.com>, akpm@linux-foundation.org
Cc: aswin@hp.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/5] ipc,msg: document volatile r_msg
Date: Sun, 18 May 2014 08:08:22 +0200	[thread overview]
Message-ID: <53784E56.4070801@colorfullife.com> (raw)
In-Reply-To: <1400012857-11733-5-git-send-email-davidlohr@hp.com>

Hi Davidlohr,

On 05/13/2014 10:27 PM, Davidlohr Bueso wrote:
> The need for volatile is not obvious, document it.
>
> Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>

In the long run, it would be great if the logic from sem.c would be 
moved to one central place.
- wake_up_sem_queue_prepare()
- wake_up_sem_queue_do()
- get_queue_result()
- the realtime compatible implementation that uses a completion instead 
of the busy loop in get_queue_result()

The code more or less just a reliable wait queue, nothing is specific to 
sysv:
- the woken up task knows if it was woken up due to a signal or due to 
wake_up_process()
- wake_up_process() out of line, after dropping all locks
- only two lock operation (one for: check that task must wait and go to 
sleep, one for: identify the task that must be woken up).

With a "normal" wait queue, there are three lock operation (notice that 
task was woken up, cleanup)


> ---
>   ipc/msg.c | 10 +++++++---
>   1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/ipc/msg.c b/ipc/msg.c
> index c2cdb5b..956cd65 100644
> --- a/ipc/msg.c
> +++ b/ipc/msg.c
> @@ -42,9 +42,7 @@
>   #include <linux/uaccess.h>
>   #include "util.h"
>   
> -/*
> - * one msg_receiver structure for each sleeping receiver:
> - */
> +/* one msg_receiver structure for each sleeping receiver */
>   struct msg_receiver {
>   	struct list_head	r_list;
>   	struct task_struct	*r_tsk;
> @@ -54,6 +52,12 @@ struct msg_receiver {
>   	long			r_msgtype;
>   	long			r_maxsize;
>   
> +	/*
> +	 * Mark r_msg volatile so that the compiler
> +	 * does not try to get smart and optimize
> +	 * it. We rely on this for the lockless
> +	 * receive algorithm.
> +	 */
>   	struct msg_msg		*volatile r_msg;
>   };
>   


  reply	other threads:[~2014-05-18  6:08 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 [this message]
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)
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=53784E56.4070801@colorfullife.com \
    --to=manfred@colorfullife.com \
    --cc=akpm@linux-foundation.org \
    --cc=aswin@hp.com \
    --cc=davidlohr@hp.com \
    --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.