[LITMUS^RT] LITMUS^RT on v4.9: call for testing

[Namhoon Kim]

On Wed, Mar 8, 2017 at 6:39 AM, Björn Brandenburg <bbb at mpi-sws.org> wrote:

>
> > On 8 Mar 2017, at 10:16, Andrea Bastoni <bastoni at sprg.uniroma2.it>
> wrote:
> > So, yes, above you need a release
> > semantics (but that should be coupled with an acquire one somewhere,
> > perhaps where the free count is checked(?) -- why is the free_count
> > incremented atomically, but not read with at least READ_ONCE? -- but
> > I'm no longer familiar with the code, sorry.)
>
> Hi Andrea,
>
> thanks for your quick reply. The corresponding atomic access is in
> ft_buffer_start_write() in litmus/feather_buffer.h.
>
> static inline int ft_buffer_start_write(struct ft_buffer* buf, void **ptr)
> {
>
> —->     int free = fetch_and_dec(&buf->free_count);
>
>         unsigned int idx;
>         if (free <= 0) {
>                 fetch_and_inc(&buf->free_count);
>                 *ptr = 0;
>                 fetch_and_inc(&buf->failed_writes);
>                 return 0;
>         } else {
>                 idx  = fetch_and_inc((int*) &buf->write_idx) %
> buf->slot_count;
>                 buf->slots[idx] = SLOT_BUSY;
>                 *ptr = ((char*) buf->buffer_mem) + idx * buf->slot_size;
>                 return 1;
>         }
> }
>
> If both instances are fully serializing (i.e., the “old” semantics of
> atomic_add_return()), then this should work fine, I think.
>
> There are also a few places where the variable is read without atomics
> (e.g., the single-writer case in the same file). This “relies” (i.e., it
> seemingly has worked to date) on the fact that word-aligned loads on x86
> are actually atomic, and the fact that the variable is not used again
> (without a cast to atomic) in the same scope. I don’t think anyone has
> reasoned about portability to other platforms much to date, or taken into
> account what future hyper-agressive compiler optimizations might result in.
>
> Hence my suggestion to convert everything to proper atomic_t variables…
> Any volunteers (not Andrea)?
>
> > In the end, yes, there's the need of a barrier after the
> > fetch_and_inc(). Probably this _untested_ patch may do the trick:
> > diff --git a/include/litmus/feather_trace.h b/include/litmus/feather_
> trace.h
> > index dbeca46..24dbc16 100644
> > --- a/include/litmus/feather_trace.h
> > +++ b/include/litmus/feather_trace.h
> > @@ -1,7 +1,7 @@
> > #ifndef _FEATHER_TRACE_H_
> > #define _FEATHER_TRACE_H_
> >
> > -#include <asm/atomic.h>
> > +#include <linux/atomic.h>
>
> Namhoon, can you confirm that this works?
>
> It works fine for our machine. I attached imx6_atomic_OP_return.patch to
fix compilation errors on ARM. I merged two previous patches from Andrea.

I also attached a patch to convert three variables in struct ft_buffer to
atomic_t variables. This patch fixes compilations errors, but I have not
tested yet. A disk drive failure has occurred on our machine, and we are
waiting for new disk drives now. After we fix the disk problems, I will
test the wip-port branch again.

Thanks,

Namhoon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20170322/9414deef/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imx6_atomic_OP_return.patch
Type: application/octet-stream
Size: 947 bytes
Desc: not available
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20170322/9414deef/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imx6_atomic_variable.patch
Type: application/octet-stream
Size: 6560 bytes
Desc: not available
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20170322/9414deef/attachment-0001.obj>