> From: Pekka Enberg [mailto:penb...@kernel.org]
> Subject: Re: [RFC/PATCH] zcache/ramster rewrite and promotion
>
> On Mon, Aug 6, 2012 at 7:10 PM, Dan Magenheimer
> wrote:
> > Hmmm.. there's also zbud.c and tmem.c which are critical components
> >
From: Pekka Enberg [mailto:penb...@kernel.org]
Subject: Re: [RFC/PATCH] zcache/ramster rewrite and promotion
On Mon, Aug 6, 2012 at 7:10 PM, Dan Magenheimer
dan.magenhei...@oracle.com wrote:
Hmmm.. there's also zbud.c and tmem.c which are critical components
of both zcache and ramster
On Mon, Aug 6, 2012 at 7:10 PM, Dan Magenheimer
wrote:
> Hmmm.. there's also zbud.c and tmem.c which are critical components
> of both zcache and ramster. And there are header files as well which
> will need to either be in mm/ or somewhere in include/linux/
>
> Is there a reason or rule that
> From: Pekka Enberg [mailto:penb...@kernel.org]
> Subject: Re: [RFC/PATCH] zcache/ramster rewrite and promotion
>
> On Mon, Aug 6, 2012 at 5:07 PM, Dan Magenheimer
> wrote:
> > I'm OK with placing it wherever kernel developers want to put
> > it, as long as the reason
On Mon, Aug 6, 2012 at 5:07 PM, Dan Magenheimer
wrote:
> I'm OK with placing it wherever kernel developers want to put
> it, as long as the reason is not NIMBY-ness. [1] My preference
> is to keep all the parts together, at least for the review phase,
> but if there is a consensus that it
> From: Pekka Enberg [mailto:penb...@kernel.org]
> Subject: Re: [RFC/PATCH] zcache/ramster rewrite and promotion
>
> Hi Dan,
>
> On Wed, Aug 1, 2012 at 12:13 AM, Dan Magenheimer
> wrote:
> > Ramster does the same thing but manages it peer-to-peer across
> > mult
From: Pekka Enberg [mailto:penb...@kernel.org]
Subject: Re: [RFC/PATCH] zcache/ramster rewrite and promotion
Hi Dan,
On Wed, Aug 1, 2012 at 12:13 AM, Dan Magenheimer
dan.magenhei...@oracle.com wrote:
Ramster does the same thing but manages it peer-to-peer across
multiple systems using
On Mon, Aug 6, 2012 at 5:07 PM, Dan Magenheimer
dan.magenhei...@oracle.com wrote:
I'm OK with placing it wherever kernel developers want to put
it, as long as the reason is not NIMBY-ness. [1] My preference
is to keep all the parts together, at least for the review phase,
but if there is a
From: Pekka Enberg [mailto:penb...@kernel.org]
Subject: Re: [RFC/PATCH] zcache/ramster rewrite and promotion
On Mon, Aug 6, 2012 at 5:07 PM, Dan Magenheimer
dan.magenhei...@oracle.com wrote:
I'm OK with placing it wherever kernel developers want to put
it, as long as the reason
On Mon, Aug 6, 2012 at 7:10 PM, Dan Magenheimer
dan.magenhei...@oracle.com wrote:
Hmmm.. there's also zbud.c and tmem.c which are critical components
of both zcache and ramster. And there are header files as well which
will need to either be in mm/ or somewhere in include/linux/
Is there a
Hi Dan,
On Wed, Aug 1, 2012 at 12:13 AM, Dan Magenheimer
wrote:
> Ramster does the same thing but manages it peer-to-peer across
> multiple systems using kernel sockets. One could argue that
> the dependency on sockets makes it more of a driver than "mm"
> but ramster is "memory management"
Hi Konrad,
> On Tue, Jul 31, 2012 at 11:53:57PM +0300, Pekka Enberg wrote:
>> Why on earth would you want to move that under the mm directory?
On Wed, Aug 1, 2012 at 12:04 AM, Konrad Rzeszutek Wilk
wrote:
> If you take aside that problem that it is one big patch instead
> of being split up in
Hi Konrad,
On Tue, Jul 31, 2012 at 11:53:57PM +0300, Pekka Enberg wrote:
Why on earth would you want to move that under the mm directory?
On Wed, Aug 1, 2012 at 12:04 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
If you take aside that problem that it is one big patch instead
of
Hi Dan,
On Wed, Aug 1, 2012 at 12:13 AM, Dan Magenheimer
dan.magenhei...@oracle.com wrote:
Ramster does the same thing but manages it peer-to-peer across
multiple systems using kernel sockets. One could argue that
the dependency on sockets makes it more of a driver than mm
but ramster is
> From: Pekka Enberg [mailto:penb...@kernel.org]
> Sent: Tuesday, July 31, 2012 2:54 PM
>
> On Tue, Jul 31, 2012 at 11:18 PM, Dan Magenheimer
> wrote:
> > diffstat vs 3.5:
> > drivers/staging/ramster/Kconfig |2
> > drivers/staging/ramster/Makefile |2
> >
On Tue, Jul 31, 2012 at 11:53:57PM +0300, Pekka Enberg wrote:
> On Tue, Jul 31, 2012 at 11:18 PM, Dan Magenheimer
> wrote:
> > diffstat vs 3.5:
> > drivers/staging/ramster/Kconfig |2
> > drivers/staging/ramster/Makefile |2
> > drivers/staging/zcache/Kconfig|2
> >
On Tue, Jul 31, 2012 at 11:18 PM, Dan Magenheimer
wrote:
> diffstat vs 3.5:
> drivers/staging/ramster/Kconfig |2
> drivers/staging/ramster/Makefile |2
> drivers/staging/zcache/Kconfig|2
> drivers/staging/zcache/Makefile |2
> mm/Kconfig
Here finally is the long promised rewrite of zcache (and ramster).
I know that we are concentrating on moving zcache from staging,
and not ramster. However the amount of duplicate code that ramster
used from zcache is astonishing so when I did the rewrite I thought
why not kill two birds with one
Here finally is the long promised rewrite of zcache (and ramster).
I know that we are concentrating on moving zcache from staging,
and not ramster. However the amount of duplicate code that ramster
used from zcache is astonishing so when I did the rewrite I thought
why not kill two birds with one
On Tue, Jul 31, 2012 at 11:18 PM, Dan Magenheimer
dan.magenhei...@oracle.com wrote:
diffstat vs 3.5:
drivers/staging/ramster/Kconfig |2
drivers/staging/ramster/Makefile |2
drivers/staging/zcache/Kconfig|2
drivers/staging/zcache/Makefile |2
On Tue, Jul 31, 2012 at 11:53:57PM +0300, Pekka Enberg wrote:
On Tue, Jul 31, 2012 at 11:18 PM, Dan Magenheimer
dan.magenhei...@oracle.com wrote:
diffstat vs 3.5:
drivers/staging/ramster/Kconfig |2
drivers/staging/ramster/Makefile |2
drivers/staging/zcache/Kconfig
From: Pekka Enberg [mailto:penb...@kernel.org]
Sent: Tuesday, July 31, 2012 2:54 PM
On Tue, Jul 31, 2012 at 11:18 PM, Dan Magenheimer
dan.magenhei...@oracle.com wrote:
diffstat vs 3.5:
drivers/staging/ramster/Kconfig |2
drivers/staging/ramster/Makefile |2
22 matches
Mail list logo
