> 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href