RE: [PATCH 3/4] zsmalloc use zs_handle instead of void *

[Dan Magenheimer]

> From: Minchan Kim [mailto:minchan@xxxxxxxxxx]
> Subject: Re: [PATCH 3/4] zsmalloc use zs_handle instead of void *
> 
> Hi Dan,
> 
> At least, zram is also primary user and it also has such mess although it's not severe than zcache.
> zram->table[index].handle sometime has real (void*) handle, sometime (struct page*).
> And I assume ramster you sent yesterday will be.
> 
> I think there are already many mess and I bet it will prevent going to mainline.
> Especially, handle problem is severe because it a arguement of most functions exported in zsmalloc
> So, we should clean up before late, IMHO.
> 
> > zcache is going to need more access to the internals
> > of its allocator, not less.  Zsmalloc is currently missing
> > some important functionality that (I believe) will be
> > necessary to turn zcache into an enterprise-ready,
> 
> If you have such TODO list, could you post it?
> It helps direction point of my stuff.

Will you be proposing to promote zram and zsmalloc out of staging
for the upcoming window?  If so, I will try to make some time
for this.  Otherwise, I apologize, but I will need to
wait a week or two (after the upcoming window) when I will
have more time.
 
> > always-on kernel feature.  If it evolves to add that
> > functionality, then it may no longer be able to provide
> > generic abstract access... in which case generic zsmalloc
> > may then have zero users in the kernel.
> 
> Hmm, Do you want to make zsmalloc by zcache owned private allocator?

I would prefer to use only zsmalloc, but it currently cannot provide
all the functionality of "zbud" which is a private allocator in
zcache and ramster.  I'll explain more later.

Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/