From: Andrew Morton <akpm@linux-foundation.org>
To: Dan Streetman <ddstreet@ieee.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
David Vrabel <david.vrabel@citrix.com>,
xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCHv2] frontswap: allow multiple backends
Date: Tue, 2 Jun 2015 14:06:20 -0700 [thread overview]
Message-ID: <20150602140620.08465687d7c69f851cd2a10f@linux-foundation.org> (raw)
In-Reply-To: <1433168544-26301-1-git-send-email-ddstreet@ieee.org>
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!
> }
> - /*
> - * 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 ;)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-06-02 21:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-28 20:28 [PATCH] " Dan Streetman
2015-05-29 22:07 ` Andrew Morton
2015-06-01 12:25 ` Dan Streetman
2015-06-01 14:22 ` [PATCHv2] " Dan Streetman
2015-06-02 21:06 ` Andrew Morton [this message]
2015-06-02 21:27 ` Dan Streetman
2015-06-02 22:08 ` [PATCHv3] " Dan Streetman
2015-06-02 22:19 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150602140620.08465687d7c69f851cd2a10f@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=ddstreet@ieee.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox