On Fri, Oct 26, 2012 at 04:45:14PM -0500, Seth Jennings wrote:
> On 10/02/2012 01:17 PM, Dan Magenheimer wrote:
> > If so, and move forward? What do you see as next steps?
>
> I've been reviewing the changes between zcache and zcache2 and getting
> a feel for the scope and direction of those
On Fri, Oct 26, 2012 at 04:45:14PM -0500, Seth Jennings wrote:
On 10/02/2012 01:17 PM, Dan Magenheimer wrote:
If so, shake hands and move forward? What do you see as next steps?
I've been reviewing the changes between zcache and zcache2 and getting
a feel for the scope and direction of
On 10/02/2012 01:17 PM, Dan Magenheimer wrote:
> If so, and move forward? What do you see as next steps?
I've been reviewing the changes between zcache and zcache2 and getting
a feel for the scope and direction of those changes.
- Getting the community engaged to review zcache1 at ~2300SLOC
On 10/02/2012 01:17 PM, Dan Magenheimer wrote:
If so, shake hands and move forward? What do you see as next steps?
I've been reviewing the changes between zcache and zcache2 and getting
a feel for the scope and direction of those changes.
- Getting the community engaged to review zcache1 at
On 10/02/2012 01:17 PM, Dan Magenheimer wrote:
> If so, and move forward? What do you see as next steps?
I'll need to get up to speed on the new codebase before I can answer
this. I should be able to answer by early next week.
Seth
--
To unsubscribe from this list: send the line "unsubscribe
On 10/02/2012 01:17 PM, Dan Magenheimer wrote:
If so, shake hands and move forward? What do you see as next steps?
I'll need to get up to speed on the new codebase before I can answer
this. I should be able to answer by early next week.
Seth
--
To unsubscribe from this list: send the line
> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
> Subject: Re: [RFC] mm: add support for zsmalloc and zcache
>
> On 09/27/2012 05:07 PM, Dan Magenheimer wrote:
> > Of course, I'm of the opinion that neither zcache1 nor
> > zcache2 would be likely to be promo
On 09/27/2012 05:07 PM, Dan Magenheimer wrote:
> Of course, I'm of the opinion that neither zcache1 nor
> zcache2 would be likely to be promoted for at least another
> cycle or two, so if you go with zcache2+zsmalloc as the compromise
> and it still takes six months for promotion, I hope you don't
On 09/28/2012 08:31 AM, Mel Gorman wrote:
> On Tue, Sep 25, 2012 at 04:31:01PM -0700, Dan Magenheimer wrote:
>> Attached patch applies to staging-next and I _think_ should
>> fix the reported problem where zbud in zcache2 does not
>> work on a PPC64 with PAGE_SIZE!=12. I do not have a machine
>>
On 09/28/2012 08:31 AM, Mel Gorman wrote:
On Tue, Sep 25, 2012 at 04:31:01PM -0700, Dan Magenheimer wrote:
Attached patch applies to staging-next and I _think_ should
fix the reported problem where zbud in zcache2 does not
work on a PPC64 with PAGE_SIZE!=12. I do not have a machine
to test
On 09/27/2012 05:07 PM, Dan Magenheimer wrote:
Of course, I'm of the opinion that neither zcache1 nor
zcache2 would be likely to be promoted for at least another
cycle or two, so if you go with zcache2+zsmalloc as the compromise
and it still takes six months for promotion, I hope you don't
From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
On 09/27/2012 05:07 PM, Dan Magenheimer wrote:
Of course, I'm of the opinion that neither zcache1 nor
zcache2 would be likely to be promoted for at least another
cycle
On Tue, Sep 25, 2012 at 04:31:01PM -0700, Dan Magenheimer wrote:
> Attached patch applies to staging-next and I _think_ should
> fix the reported problem where zbud in zcache2 does not
> work on a PPC64 with PAGE_SIZE!=12. I do not have a machine
> to test this so testing by others would be
On Tue, Sep 25, 2012 at 04:31:01PM -0700, Dan Magenheimer wrote:
Attached patch applies to staging-next and I _think_ should
fix the reported problem where zbud in zcache2 does not
work on a PPC64 with PAGE_SIZE!=12. I do not have a machine
to test this so testing by others would be
> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
> Subject: Re: [RFC] mm: add support for zsmalloc and zcache
>
> On 09/24/2012 02:17 PM, Dan Magenheimer wrote:
> >> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
> >> Subject: Re: [RFC] mm: add s
On 09/24/2012 02:17 PM, Dan Magenheimer wrote:
>> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
>> Subject: Re: [RFC] mm: add support for zsmalloc and zcache
>
> Once again, you have completely ignored a reasonable
> compromise proposal. Why?
We have use
On 09/24/2012 02:17 PM, Dan Magenheimer wrote:
From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
Once again, you have completely ignored a reasonable
compromise proposal. Why?
We have users who are interested in zcache
From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
On 09/24/2012 02:17 PM, Dan Magenheimer wrote:
From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
Once
Attached patch applies to staging-next and I _think_ should
fix the reported problem where zbud in zcache2 does not
work on a PPC64 with PAGE_SIZE!=12. I do not have a machine
to test this so testing by others would be appreciated.
Ideally there should also be a BUILD_BUG_ON to ensure
PAGE_SHIFT
Attached patch applies to staging-next and adds zsmalloc
support, optionally at compile-time and run-time, back into
zcache (aka zcache2). It is only lightly tested and does
not provide some of the debug info from old zcache (aka zcache1)
because it needs to be converted from sysfs to debugfs.
> From: Sasha Levin [mailto:levinsasha...@gmail.com]
> Subject: Re: [RFC] mm: add support for zsmalloc and zcache
Sorry for delayed response!
> On 09/22/2012 03:31 PM, Sasha Levin wrote:
> > On 09/21/2012 09:14 PM, Dan Magenheimer wrote:
> >>>> +#define MAX_CLIENT
On Mon, 2012-09-24 at 12:25 -0500, Seth Jennings wrote:
> In summary, I really don't understand the objection to
> promoting zcache and integrating zcache2 improvements and
> features incrementally. It seems very natural and
> straightforward to me. Rewrites can even happen in
> mainline, as
On Mon, Sep 24, 2012 at 01:36:48PM -0700, Dan Magenheimer wrote:
> > From: Mel Gorman [mailto:mgor...@suse.de]
> > Subject: Re: [RFC] mm: add support for zsmalloc and zcache
> >
> > On Sat, Sep 22, 2012 at 02:18:44PM -0700, Dan Magenheimer wrote:
> > > > From
On Mon, Sep 24, 2012 at 01:36:48PM -0700, Dan Magenheimer wrote:
From: Mel Gorman [mailto:mgor...@suse.de]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
On Sat, Sep 22, 2012 at 02:18:44PM -0700, Dan Magenheimer wrote:
From: Mel Gorman [mailto:mgor...@suse.de]
Subject
On Mon, 2012-09-24 at 12:25 -0500, Seth Jennings wrote:
In summary, I really don't understand the objection to
promoting zcache and integrating zcache2 improvements and
features incrementally. It seems very natural and
straightforward to me. Rewrites can even happen in
mainline, as James
From: Sasha Levin [mailto:levinsasha...@gmail.com]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
Sorry for delayed response!
On 09/22/2012 03:31 PM, Sasha Levin wrote:
On 09/21/2012 09:14 PM, Dan Magenheimer wrote:
+#define MAX_CLIENTS 16
Seems a bit arbitrary. Why 16
Attached patch applies to staging-next and adds zsmalloc
support, optionally at compile-time and run-time, back into
zcache (aka zcache2). It is only lightly tested and does
not provide some of the debug info from old zcache (aka zcache1)
because it needs to be converted from sysfs to debugfs.
Attached patch applies to staging-next and I _think_ should
fix the reported problem where zbud in zcache2 does not
work on a PPC64 with PAGE_SIZE!=12. I do not have a machine
to test this so testing by others would be appreciated.
Ideally there should also be a BUILD_BUG_ON to ensure
PAGE_SHIFT
> From: Mel Gorman [mailto:mgor...@suse.de]
> Subject: Re: [RFC] mm: add support for zsmalloc and zcache
>
> On Sat, Sep 22, 2012 at 02:18:44PM -0700, Dan Magenheimer wrote:
> > > From: Mel Gorman [mailto:mgor...@suse.de]
> > > Subject: Re: [RFC] mm: add s
> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> Subject: Re: [RFC] mm: add support for zsmalloc and zcache
> On Sat, 2012-09-22 at 02:07 +0100, Mel Gorman wrote:
> > > The two proposals:
> > > A) Recreate all the work done for z
> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
> Subject: Re: [RFC] mm: add support for zsmalloc and zcache
Once again, you have completely ignored a reasonable
compromise proposal. Why?
> According to Greg's staging-next, ramster adds 6000 lines of
> new co
On 09/21/2012 03:35 PM, Dan Magenheimer wrote:
>> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
>> Subject: Re: [RFC] mm: add support for zsmalloc and zcache
>>
>> On 09/21/2012 01:02 PM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Sep 21, 2012 at 0
On Sat, Sep 22, 2012 at 02:18:44PM -0700, Dan Magenheimer wrote:
> > From: Mel Gorman [mailto:mgor...@suse.de]
> > Subject: Re: [RFC] mm: add support for zsmalloc and zcache
> >
> > On Fri, Sep 21, 2012 at 01:35:15PM -0700, Dan Magenheimer wrote:
> > > &g
On Sat, Sep 22, 2012 at 02:18:44PM -0700, Dan Magenheimer wrote:
From: Mel Gorman [mailto:mgor...@suse.de]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
On Fri, Sep 21, 2012 at 01:35:15PM -0700, Dan Magenheimer wrote:
From: Seth Jennings [mailto:sjenn
On 09/21/2012 03:35 PM, Dan Magenheimer wrote:
From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
On 09/21/2012 01:02 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 21, 2012 at 05:12:52PM +0100, Mel Gorman wrote:
On Tue, Sep 04
From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
Once again, you have completely ignored a reasonable
compromise proposal. Why?
According to Greg's staging-next, ramster adds 6000 lines of
new code to zcache
From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
On Sat, 2012-09-22 at 02:07 +0100, Mel Gorman wrote:
The two proposals:
A) Recreate all the work done for zcache2 as a proper sequence of
independent
From: Mel Gorman [mailto:mgor...@suse.de]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
On Sat, Sep 22, 2012 at 02:18:44PM -0700, Dan Magenheimer wrote:
From: Mel Gorman [mailto:mgor...@suse.de]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
On Fri, Sep 21
On Sat, 2012-09-22 at 02:07 +0100, Mel Gorman wrote:
> > The two proposals:
> > A) Recreate all the work done for zcache2 as a proper sequence of
> >independent patches and apply them to zcache1. (Seth/Konrad)
> > B) Add zsmalloc back in to zcache2 as an alternative allocator
> >for
On Sat, 2012-09-22 at 02:07 +0100, Mel Gorman wrote:
The two proposals:
A) Recreate all the work done for zcache2 as a proper sequence of
independent patches and apply them to zcache1. (Seth/Konrad)
B) Add zsmalloc back in to zcache2 as an alternative allocator
for frontswap pages.
> From: Mel Gorman [mailto:mgor...@suse.de]
> Subject: Re: [RFC] mm: add support for zsmalloc and zcache
>
> On Fri, Sep 21, 2012 at 01:35:15PM -0700, Dan Magenheimer wrote:
> > > From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
> > > Subject: Re: [RFC
On 09/22/2012 03:31 PM, Sasha Levin wrote:
> On 09/21/2012 09:14 PM, Dan Magenheimer wrote:
+#define MAX_CLIENTS 16
Seems a bit arbitrary. Why 16?
>> Sasha Levin posted a patch to fix this but it was tied in to
>> the proposed KVM implementation, so was never merged.
>>
>
> My
On 09/21/2012 09:14 PM, Dan Magenheimer wrote:
>>> +#define MAX_CLIENTS 16
>> >
>> > Seems a bit arbitrary. Why 16?
> Sasha Levin posted a patch to fix this but it was tied in to
> the proposed KVM implementation, so was never merged.
>
My patch changed the max pools per client, not the maximum
On 09/21/2012 09:14 PM, Dan Magenheimer wrote:
+#define MAX_CLIENTS 16
Seems a bit arbitrary. Why 16?
Sasha Levin posted a patch to fix this but it was tied in to
the proposed KVM implementation, so was never merged.
My patch changed the max pools per client, not the maximum amount of
On 09/22/2012 03:31 PM, Sasha Levin wrote:
On 09/21/2012 09:14 PM, Dan Magenheimer wrote:
+#define MAX_CLIENTS 16
Seems a bit arbitrary. Why 16?
Sasha Levin posted a patch to fix this but it was tied in to
the proposed KVM implementation, so was never merged.
My patch changed the max
From: Mel Gorman [mailto:mgor...@suse.de]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
On Fri, Sep 21, 2012 at 01:35:15PM -0700, Dan Magenheimer wrote:
From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
On Fri, Sep 21, 2012 at 01:35:15PM -0700, Dan Magenheimer wrote:
> > From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
> > Subject: Re: [RFC] mm: add support for zsmalloc and zcache
> >
> > On 09/21/2012 01:02 PM, Konrad Rzeszutek Wilk wrote:
> > > On Fri,
On Fri, Sep 21, 2012 at 12:14:39PM -0700, Dan Magenheimer wrote:
> Hi Mel --
>
> Wow! An incredibly wonderfully detailed response! Thank you very
> much for taking the time to read through all of zcache!
>
My pleasure.
> Your comments run the gamut from nit and code style, to design,
>
> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
> Subject: Re: [RFC] mm: add support for zsmalloc and zcache
>
> On 09/21/2012 01:02 PM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Sep 21, 2012 at 05:12:52PM +0100, Mel Gorman wrote:
> >> On Tue, Sep 04, 201
On 09/21/2012 11:12 AM, Mel Gorman wrote:
> That said, my initial feeling still stands. I think that this needs to move
> out of staging because it's in limbo where it is but Andrew may disagree
> because of the reservations. If my reservations are accurate then they
> should at least be *clearly*
Hi Mel --
Wow! An incredibly wonderfully detailed response! Thank you very
much for taking the time to read through all of zcache!
Your comments run the gamut from nit and code style, to design,
architecture and broad naming. Until the choice-of-codebase issue
is resolved, I'll avoid the nits
On 09/21/2012 01:02 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 21, 2012 at 05:12:52PM +0100, Mel Gorman wrote:
>> On Tue, Sep 04, 2012 at 04:34:46PM -0500, Seth Jennings wrote:
>>> zcache is the remaining piece of code required to support in-kernel
>>> memory compression. The other two
On Fri, Sep 21, 2012 at 05:12:52PM +0100, Mel Gorman wrote:
> On Tue, Sep 04, 2012 at 04:34:46PM -0500, Seth Jennings wrote:
> > zcache is the remaining piece of code required to support in-kernel
> > memory compression. The other two features, cleancache and frontswap,
> > have been promoted to
On Fri, Sep 21, 2012 at 05:12:52PM +0100, Mel Gorman wrote:
On Tue, Sep 04, 2012 at 04:34:46PM -0500, Seth Jennings wrote:
zcache is the remaining piece of code required to support in-kernel
memory compression. The other two features, cleancache and frontswap,
have been promoted to
On 09/21/2012 01:02 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 21, 2012 at 05:12:52PM +0100, Mel Gorman wrote:
On Tue, Sep 04, 2012 at 04:34:46PM -0500, Seth Jennings wrote:
zcache is the remaining piece of code required to support in-kernel
memory compression. The other two features,
Hi Mel --
Wow! An incredibly wonderfully detailed response! Thank you very
much for taking the time to read through all of zcache!
Your comments run the gamut from nit and code style, to design,
architecture and broad naming. Until the choice-of-codebase issue
is resolved, I'll avoid the nits
On 09/21/2012 11:12 AM, Mel Gorman wrote:
That said, my initial feeling still stands. I think that this needs to move
out of staging because it's in limbo where it is but Andrew may disagree
because of the reservations. If my reservations are accurate then they
should at least be *clearly*
From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
On 09/21/2012 01:02 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 21, 2012 at 05:12:52PM +0100, Mel Gorman wrote:
On Tue, Sep 04, 2012 at 04:34:46PM -0500, Seth Jennings
On Fri, Sep 21, 2012 at 12:14:39PM -0700, Dan Magenheimer wrote:
Hi Mel --
Wow! An incredibly wonderfully detailed response! Thank you very
much for taking the time to read through all of zcache!
My pleasure.
Your comments run the gamut from nit and code style, to design,
architecture
On Fri, Sep 21, 2012 at 01:35:15PM -0700, Dan Magenheimer wrote:
From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
On 09/21/2012 01:02 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 21, 2012 at 05:12:52PM +0100, Mel Gorman
On Mon, Sep 17, 2012 at 1:42 PM, Dan Magenheimer
wrote:
>> From: Nitin Gupta [mailto:ngu...@vflare.org]
>> Subject: Re: [RFC] mm: add support for zsmalloc and zcache
>>
>> The problem is that zbud performs well only when a (compressed) page is
>> either PAGE_SIZE/2
> From: Nitin Gupta [mailto:ngu...@vflare.org]
> Subject: Re: [RFC] mm: add support for zsmalloc and zcache
>
> The problem is that zbud performs well only when a (compressed) page is
> either PAGE_SIZE/2 - e or PAGE_SIZE - e, where e is small. So, even if
> the average compr
From: Nitin Gupta [mailto:ngu...@vflare.org]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
The problem is that zbud performs well only when a (compressed) page is
either PAGE_SIZE/2 - e or PAGE_SIZE - e, where e is small. So, even if
the average compression ratio is 2x (which
On Mon, Sep 17, 2012 at 1:42 PM, Dan Magenheimer
dan.magenhei...@oracle.com wrote:
From: Nitin Gupta [mailto:ngu...@vflare.org]
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
The problem is that zbud performs well only when a (compressed) page is
either PAGE_SIZE/2 - e
On 09/07/2012 07:37 AM, Konrad Rzeszutek Wilk wrote:
significant design challenges exist, many of which are already resolved in
the new codebase ("zcache2"). These design issues include:
.. snip..
Before other key mm maintainers read and comment on zcache, I think
it would be most wise to
On 09/07/2012 07:37 AM, Konrad Rzeszutek Wilk wrote:
significant design challenges exist, many of which are already resolved in
the new codebase (zcache2). These design issues include:
.. snip..
Before other key mm maintainers read and comment on zcache, I think
it would be most wise to move
On 09/06/2012 03:37 PM, Dan Magenheimer wrote:
> In response to this RFC for zcache promotion, I've been asked to summarize
> the concerns and objections which led me to NACK the previous zcache
> promotion request. While I see great potential in zcache, I think some
> significant design
> significant design challenges exist, many of which are already resolved in
> the new codebase ("zcache2"). These design issues include:
.. snip..
> Before other key mm maintainers read and comment on zcache, I think
> it would be most wise to move to a codebase which resolves the known design
>
significant design challenges exist, many of which are already resolved in
the new codebase (zcache2). These design issues include:
.. snip..
Before other key mm maintainers read and comment on zcache, I think
it would be most wise to move to a codebase which resolves the known design
On 09/06/2012 03:37 PM, Dan Magenheimer wrote:
In response to this RFC for zcache promotion, I've been asked to summarize
the concerns and objections which led me to NACK the previous zcache
promotion request. While I see great potential in zcache, I think some
significant design challenges
In response to this RFC for zcache promotion, I've been asked to summarize
the concerns and objections which led me to NACK the previous zcache
promotion request. While I see great potential in zcache, I think some
significant design challenges exist, many of which are already resolved in
the new
In response to this RFC for zcache promotion, I've been asked to summarize
the concerns and objections which led me to NACK the previous zcache
promotion request. While I see great potential in zcache, I think some
significant design challenges exist, many of which are already resolved in
the new
72 matches
Mail list logo
