All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>,
	devel@linuxdriverproject.org, linux-kernel@vger.kernel.org,
	gregkh@linuxfoundation.org, linux-mm@kvack.org,
	ngupta@vflare.org, minchan@kernel.org, fschmaus@gmail.com,
	andor.daam@googlemail.com, ilendir@googlemail.com,
	akpm@linux-foundation.org, mgorman@suse.de
Subject: Re: [PATCH 2/5] mm: frontswap: lazy initialization to allow tmem backends to build/run as modules
Date: Fri, 2 Nov 2012 14:24:30 -0400	[thread overview]
Message-ID: <20121102182429.GA30100@konrad-lan.dumpdata.com> (raw)
In-Reply-To: <d7588a48-9f47-4f3a-852c-3fac916de75c@default>

> > > +	frontswap_enabled = 1;
> > 
> > If frontswap_enabled is going to be on all the time, then what point
> > does it serve?  By extension, can all of the static inline wrappers in
> > frontswap.h be done away with?

Hm, or the frontswap_enabled can be converted to a "frontswap_flag"
which has:

#define FRONTSWAP_ON (1<<1)
#define FRONTSWAP_BACKEND_ON (1<<2)

or so? And then we can see if we can squash the 'backend_registerd'
and 'frontswap_enabled' together.
> 
> The intent of frontswap_enabled and cleancache_enabled was
> to avoid the overhead of a function call at the point where
> each frontswap/cleancache "hooks" is placed, using a global
> variable check instead.  I'm not sure if this minor
> performance tuning effort is worth preserving:  If not,
> I agree frontswap_enabled and the static inline wrappers (as
> well as their cleancache brethren) could be done away with **;
> if worth preserving, then I think frontswap_enabled could
> be set in the init method instead but the check for enabled
> in the frontswap init method and the cleancache init_fs
> method would need to be removed else lazy initialization
> wouldn't work.

Either way, that should be a seperate patch.
> 
> Dan
> 
> ** Note to anyone that tries this:  There is a subtle but
> clever hack in the wrappers suggested by Jeremy Fitzhardinge
> that disables the wrappers at compile-time as well as
> runtime.  IOW, make sure you test-compile both with
> CONFIG_{CLEANCACHE|FRONTSWAP} _and_ with them unconfig'd.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

--
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>

WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>,
	devel@linuxdriverproject.org, linux-kernel@vger.kernel.org,
	gregkh@linuxfoundation.org, linux-mm@kvack.org,
	ngupta@vflare.org, minchan@kernel.org, fschmaus@gmail.com,
	andor.daam@googlemail.com, ilendir@googlemail.com,
	akpm@linux-foundation.org, mgorman@suse.de
Subject: Re: [PATCH 2/5] mm: frontswap: lazy initialization to allow tmem backends to build/run as modules
Date: Fri, 2 Nov 2012 14:24:30 -0400	[thread overview]
Message-ID: <20121102182429.GA30100@konrad-lan.dumpdata.com> (raw)
In-Reply-To: <d7588a48-9f47-4f3a-852c-3fac916de75c@default>

> > > +	frontswap_enabled = 1;
> > 
> > If frontswap_enabled is going to be on all the time, then what point
> > does it serve?  By extension, can all of the static inline wrappers in
> > frontswap.h be done away with?

Hm, or the frontswap_enabled can be converted to a "frontswap_flag"
which has:

#define FRONTSWAP_ON (1<<1)
#define FRONTSWAP_BACKEND_ON (1<<2)

or so? And then we can see if we can squash the 'backend_registerd'
and 'frontswap_enabled' together.
> 
> The intent of frontswap_enabled and cleancache_enabled was
> to avoid the overhead of a function call at the point where
> each frontswap/cleancache "hooks" is placed, using a global
> variable check instead.  I'm not sure if this minor
> performance tuning effort is worth preserving:  If not,
> I agree frontswap_enabled and the static inline wrappers (as
> well as their cleancache brethren) could be done away with **;
> if worth preserving, then I think frontswap_enabled could
> be set in the init method instead but the check for enabled
> in the frontswap init method and the cleancache init_fs
> method would need to be removed else lazy initialization
> wouldn't work.

Either way, that should be a seperate patch.
> 
> Dan
> 
> ** Note to anyone that tries this:  There is a subtle but
> clever hack in the wrappers suggested by Jeremy Fitzhardinge
> that disables the wrappers at compile-time as well as
> runtime.  IOW, make sure you test-compile both with
> CONFIG_{CLEANCACHE|FRONTSWAP} _and_ with them unconfig'd.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

  reply	other threads:[~2012-11-02 18:26 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-31 15:07 [PATCH 0/5] enable all tmem backends to be built and loaded as modules Dan Magenheimer
2012-10-31 15:07 ` Dan Magenheimer
2012-10-31 15:07 ` [PATCH 1/5] mm: cleancache: lazy initialization to allow tmem backends to build/run " Dan Magenheimer
2012-10-31 15:07   ` Dan Magenheimer
2012-11-02 18:29   ` Konrad Rzeszutek Wilk
2012-11-02 18:29     ` Konrad Rzeszutek Wilk
2012-10-31 15:07 ` [PATCH 2/5] mm: frontswap: " Dan Magenheimer
2012-10-31 15:07   ` Dan Magenheimer
2012-10-31 17:05   ` Seth Jennings
2012-10-31 17:05     ` Seth Jennings
2012-10-31 21:42     ` Cesar Eduardo Barros
2012-10-31 21:42       ` Cesar Eduardo Barros
2012-11-01 15:30     ` Dan Magenheimer
2012-11-01 15:30       ` Dan Magenheimer
2012-11-02 18:24       ` Konrad Rzeszutek Wilk [this message]
2012-11-02 18:24         ` Konrad Rzeszutek Wilk
2012-11-02 18:27     ` Konrad Rzeszutek Wilk
2012-11-02 18:27       ` Konrad Rzeszutek Wilk
2012-11-03  1:21       ` Bob Liu
2012-11-03  1:21         ` Bob Liu
2012-11-14 16:25         ` Konrad Rzeszutek Wilk
2012-11-14 16:25           ` Konrad Rzeszutek Wilk
2012-10-31 15:07 ` [PATCH 3/5] staging: zcache2+ramster: enable zcache2 to be built/loaded as a module Dan Magenheimer
2012-10-31 15:07   ` Dan Magenheimer
2012-11-02 18:39   ` Konrad Rzeszutek Wilk
2012-11-02 18:39     ` Konrad Rzeszutek Wilk
2012-10-31 15:07 ` [PATCH 4/5] staging: zcache2+ramster: enable ramster " Dan Magenheimer
2012-10-31 15:07   ` Dan Magenheimer
2012-10-31 15:07 ` [PATCH 5/5] xen: tmem: enable Xen tmem shim " Dan Magenheimer
2012-10-31 15:07   ` Dan Magenheimer

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=20121102182429.GA30100@konrad-lan.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=andor.daam@googlemail.com \
    --cc=dan.magenheimer@oracle.com \
    --cc=devel@linuxdriverproject.org \
    --cc=fschmaus@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ilendir@googlemail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=minchan@kernel.org \
    --cc=ngupta@vflare.org \
    --cc=sjenning@linux.vnet.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.