[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCHv2] frontswap: allow multiple backends
On Tue, Jun 2, 2015 at 5:06 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > 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! 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 :-) > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |