lkml.org 
[lkml]   [2015]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCHv2] frontswap: allow multiple backends
On Tue, Jun 2, 2015 at 5:06 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Mon, 1 Jun 2015 10:22:24 -0400 Dan Streetman <ddstreet@ieee.org> 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!

Doh! I'll fix and resend.

I did test it, too, but zswap doesn't care if the swap device actually
exists, it just alloc's a tree for whatever it's told. So likely it
was allocing some extra trees there :)

>
>> }
>> - /*
>> - * 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 ;)

okay, okay :-)

>
>


\
 
 \ /
  Last update: 2015-06-03 00:21    [W:0.059 / U:9.960 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site