lkml.org 
[lkml]   [2008]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [TOMOYO #10 (linux-next) 7/8] File operation restriction part.
    On Sun, Oct 19, 2008 at 10:10:23PM +0900, Tetsuo Handa wrote:
    > Hello.
    >
    > Paul E. McKenney wrote:
    > > > Maybe I'm misunderstanding what "mb()" can do.
    > >
    > > The problem is that while wmb() and mb() do in fact order writes, they
    > > cannot order the other task's reads.
    > >
    > I expected that "mb()" can order the other task's reads.

    So did I, a long time ago. It took an Alpha architect more than
    an hour face-to-face to convince me otherwise. ;-)

    > Now, I understood that there is no room for optimizing the reader process
    > by omitting smp_read_barrier_depends() on read side.
    >
    > OK, let's return to http://lkml.org/lkml/2008/10/14/406 .
    > Below is the updated version of list1 operations.
    > As I now use rcu_assign_pointer() and rcu_dereference() which depend on
    > include/linux/rcupdate.h , I separated the code from include/linux/list.h .
    > Did I update correctly?
    >
    > ---
    > Subject: Singly linked list implementation.

    Looks good to me!

    Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

    > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    > ---
    > include/linux/list1.h | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++
    > 1 file changed, 81 insertions(+)
    >
    > --- /dev/null
    > +++ linux-next/include/linux/list1.h
    > @@ -0,0 +1,81 @@
    > +#ifndef _LINUX_LIST1_H
    > +#define _LINUX_LIST1_H
    > +
    > +#include <linux/list.h>
    > +#include <linux/rcupdate.h>
    > +
    > +/*
    > + * Singly linked list implementation.
    > + *
    > + * This list supports only two operations.
    > + * (1) Append an entry to the tail of the list.
    > + * (2) Read all entries starting from the head of the list.
    > + *
    > + * This list is designed for holding "write once, read many" entries.
    > + * This list requires no locks for read operation.
    > + * This list doesn't support "remove an entry from the list" operation.
    > + */
    > +
    > +/* To reduce memory usage, this list doesn't use "->prev" pointer. */
    > +struct list1_head {
    > + struct list1_head *next;
    > +};
    > +
    > +#define LIST1_HEAD_INIT(name) { &(name) }
    > +#define LIST1_HEAD(name) struct list1_head name = LIST1_HEAD_INIT(name)
    > +
    > +static inline void INIT_LIST1_HEAD(struct list1_head *list)
    > +{
    > + list->next = list;
    > +}
    > +
    > +/* Reuse list_entry because it doesn't use "->prev" pointer. */
    > +#define list1_entry list_entry
    > +
    > +/* Reuse list_for_each_rcu because it doesn't use "->prev" pointer. */
    > +#define list1_for_each list_for_each_rcu
    > +/* Reuse list_for_each_entry_rcu because it doesn't use "->prev" pointer. */
    > +#define list1_for_each_entry list_for_each_entry_rcu
    > +
    > +/**
    > + * list1_for_each_cookie - iterate over a list with cookie.
    > + * @pos: the &struct list1_head to use as a loop cursor.
    > + * @cookie: the &struct list1_head to use as a cookie.
    > + * @head: the head for your list.
    > + *
    > + * Same with list_for_each_rcu() except that this primitive uses @cookie
    > + * so that we can continue iteration.
    > + * @cookie must be NULL when iteration starts, and @cookie will become
    > + * NULL when iteration finishes.
    > + *
    > + * Since list elements are never removed, we don't need to get a lock
    > + * or a reference count.
    > + */
    > +#define list1_for_each_cookie(pos, cookie, head) \
    > + for (({ if (!cookie) \
    > + cookie = head; }), \
    > + pos = rcu_dereference((cookie)->next); \
    > + prefetch(pos->next), pos != (head) || ((cookie) = NULL); \
    > + (cookie) = pos, pos = rcu_dereference(pos->next))
    > +
    > +/**
    > + * list1_add_tail - add a new entry to list1 list.
    > + * @new: new entry to be added.
    > + * @head: list head to add it before.
    > + *
    > + * Same with list_add_tail_rcu() without "->prev" pointer.
    > + *
    > + * Caller must hold a lock for protecting @head.
    > + */
    > +static inline void list1_add_tail(struct list1_head *new,
    > + struct list1_head *head)
    > +{
    > + struct list1_head *prev = head;
    > +
    > + new->next = head;
    > + while (prev->next != head)
    > + prev = prev->next;
    > + rcu_assign_pointer(prev->next, new);
    > +}
    > +
    > +#endif
    > ---
    >
    > By the way, quoting from ordering.2007.09.19a.pdf :
    >
    > | One could place an smp_rmb() primitive between the pointer fetch and
    > | dereference. However, this imposes unneeded overhead on systems (such as
    > | i386, IA64, PPC, and SPARC) that respect data dependencies on the read side.
    > | A smp_read_barrier_depends() primitive has been added to the Linux 2.6 kernel
    > | to eliminate overhead on these systems.
    >
    > In 2.4 kernels, to support Alpha architecture, people use smp_rmb() which
    > imposes unneeded overhead on non Alpha architecture.
    > In 2.6 kernels, to support Alpha architecture, people use
    > smp_read_barrier_depends() which does not impose unneeded overhead on
    > non Alpha architecture.
    > That's nice.
    >
    > | Alpha is the only CPU where smp_read_barrier_depends() is an smp_mb() rather
    > | than a no-op.
    >
    > I found
    >
    > #define smp_read_barrier_depends() read_barrier_depends()
    >
    > in arch/h8300/include/asm/system.h but couldn't find the definition of
    > read_barrier_depends() within that file.
    > I hope read_barrier_depends() is defined as a no-op by some other header files.
    >
    > Regards.


    \
     
     \ /
      Last update: 2008-10-20 06:21    [W:0.080 / U:0.544 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site