[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCHv2] frontswap: allow multiple backends



On Mon,  1 Jun 2015 10:22:24 -0400 Dan Streetman <ddstreet@xxxxxxxx> wrote:

> Change frontswap single pointer to a singly linked list of frontswap
> implementations.  Update Xen tmem implementation as register no longer
> returns anything.
> 
> Frontswap only keeps track of a single implementation; any implementation
> that registers second (or later) will replace the previously registered
> implementation, and gets a pointer to the previous implementation that
> the new implementation is expected to pass all frontswap functions to
> if it can't handle the function itself.  However that method doesn't
> really make much sense, as passing that work on to every implementation
> adds unnecessary work to implementations; instead, frontswap should
> simply keep a list of all registered implementations and try each
> implementation for any function.  Most importantly, neither of the
> two currently existing frontswap implementations in the kernel actually
> do anything with any previous frontswap implementation that they
> replace when registering.
> 
> This allows frontswap to successfully manage multiple implementations
> by keeping a list of them all.
> 
> ...
>
> -struct frontswap_ops *frontswap_register_ops(struct frontswap_ops *ops)
> +void frontswap_register_ops(struct frontswap_ops *ops)
>  {
> -     struct frontswap_ops *old = frontswap_ops;
> -     int i;
> -
> -     for (i = 0; i < MAX_SWAPFILES; i++) {
> -             if (test_and_clear_bit(i, need_init)) {
> -                     struct swap_info_struct *sis = swap_info[i];
> -                     /* __frontswap_init _should_ have set it! */
> -                     if (!sis->frontswap_map)
> -                             return ERR_PTR(-EINVAL);
> -                     ops->init(i);
> -             }
> +     DECLARE_BITMAP(a, MAX_SWAPFILES);
> +     DECLARE_BITMAP(b, MAX_SWAPFILES);
> +     struct swap_info_struct *si;
> +     unsigned int i;
> +
> +     spin_lock(&swap_lock);
> +     plist_for_each_entry(si, &swap_active_head, list) {
> +             if (!WARN_ON(!si->frontswap_map))
> +                     set_bit(si->type, a);

umm, DECLARE_BITMAP() doesn't initialise the storage.  Either this
patch wasn't tested very well or you should buy me a lottery ticket!

>       }
> -     /*
> -      * We MUST have frontswap_ops set _after_ the frontswap_init's
> -      * have been called. Otherwise __frontswap_store might fail. Hence
> -      * the barrier to make sure compiler does not re-order us.
> +     spin_unlock(&swap_lock);
> +
> +     /* the new ops needs to know the currently active swap devices */
> +     for_each_set_bit(i, a, MAX_SWAPFILES)
> +             ops->init(i);
> +
> +     /* setting frontswap_ops must happen after the ops->init() calls
> +      * above; cmpxchg implies smp_mb() which will ensure the init is
> +      * complete at this point
> +      */

Like this, please:

        /*
         * Setting ...

and sentences start with capital letters ;)



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.