From: Nitin Gupta <ngupta@vflare.org>
To: Minchan Kim <minchan@kernel.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] zsmalloc use zs_handle instead of void *
Date: Mon, 14 May 2012 21:57:19 -0400 [thread overview]
Message-ID: <CAPkvG_dTA7HwzVBo70bZuqkX+ZfjJpS+p4L9L+jF4Uz1ooEx0Q@mail.gmail.com> (raw)
In-Reply-To: <4FB06B91.1080008@kernel.org>
On Sun, May 13, 2012 at 10:18 PM, Minchan Kim <minchan@kernel.org> wrote:
> On 05/12/2012 04:28 AM, Konrad Rzeszutek Wilk wrote:
>
>>> Please look.
>>>
>>> struct zs_handle {
>>> void *handle
>>> };
>>>
>>> 1)
>>>
>>> static struct zv_hdr *zv_create(..)
>>> {
>>> struct zs_handle handle;
>>> ..
>>> handle = zs_malloc(pool, size);
>>> ..
>>> return handle;
>>
>> Compiler will complain that you are returning incorrect type.
>
>
> My bad. &handle.
>
>>
>>> }
>>>
>>> handle is on stack so it can't be used by index for slot of radix tree.
>>
>> The fix is of course to return a pointer (which your function
>> declared), and instead do this:
>>
>> {
>> struct zs_handle *handle;
>>
>> handle = zs_malloc(pool, size);
>
>
> It's not a good idea.
> For it, zs_malloc needs memory space to keep zs_handle internally.
> Why should zsallocator do it? Just for zcache?
> It's not good abstraction.
>
>
>> return handle;
>> }
>>
>>>
>>> 2)
>>>
>>> static struct zv_hdr *zv_create(..)
>>> {
>>> struct zs_handle handle;
>>> ..
>>> handle = zs_malloc(pool, size);
>>> ..
>>> return handle.handle;
>>> }
>>>
>>> Okay. Now it works but zcache coupled with zsmalloc tightly.
>>> User of zsmalloc should never know internal of zs_handle.
>>
>> OK. Then it can just forward declare it:
>>
>> struct zs_handle;
>>
>> and zsmalloc will treat it as an opaque pointer.
>>
>>>
>>> 3)
>>>
>>> - zsmalloc.h
>>> void *zs_handle_to_ptr(struct zs_handle handle)
>>> {
>>> return handle.hanle;
>>> }
>>>
>>> static struct zv_hdr *zv_create(..)
>>> {
>>> struct zs_handle handle;
>>> ..
>>> handle = zs_malloc(pool, size);
>>> ..
>>> return zs_handle_to_ptr(handle);
>>
>>> }
>>
>>>
>>> Why should zsmalloc support such interface?
>>
>> Why not? It is better than a 'void *' or a typedef.
>>
>> It is modeled after a pte_t.
>
>
> It's not same with pte_t.
> We normally don't use pte_val to (void*) for unique index of slot.
> The problem is that zcache assume handle of zsmalloc is a sizeof(void*)'s
> unique value but zcache never assume it's a sizeof(void*).
>
>>
>>
>>> It's a zcache problem so it's desriable to solve it in zcache internal.
>>
>> Not really. We shouldn't really pass any 'void *' pointers around.
>>
>>> And in future, if we can add/remove zs_handle's fields, we can't make
>>> sure such API.
>>
>> Meaning ... what exactly do you mean? That the size of the structure
>> will change and we won't return the right value? Why not?
>> If you use the 'zs_handle_to_ptr' won't that work? Especially if you
>> add new values to the end of the struct it won't cause issues.
>
>
> I mean we might change zs_handle to following as, in future.
> (It's insane but who know it?)
>
> struct zs_handle {
> int upper;
> int middle;
> int lower;
> };
>
> How could you handle this for zs_handle_to_ptr?
>
>>
>>>
>>>
>>>>> Its true that making it a real struct would prevent accidental casts
>>>>> to void * but due to the above problem, I think we have to stick
>>>>> with unsigned long.
>>
>> So the problem you are seeing is that you don't want 'struct zs_handle'
>> be present in the drivers/staging/zsmalloc/zsmalloc.h header file?
>> It looks like the proper place.
>
>
> No. What I want is to remove coupling zsallocator's handle with zram/zcache.
> They shouldn't know internal of handle and assume it's a pointer.
>
> If Nitin confirm zs_handle's format can never change in future, I prefer "unsigned long" Nitin suggested than (void *).
> It can prevent confusion that normal allocator's return value is pointer for address so the problem is easy.
> But I am not sure he can make sure it.
>
zs_handle will always be an unsigned long so its better to just use
the same as return type.
Another alternative is to return 'struct zs_handle *' which can be
used as a 'void *' by zcache and as unsigned long by zsmalloc.
However, I see no good reason for preferring this over simple unsigned
long as the return type.
Thanks,
Nitin
next prev parent reply other threads:[~2012-05-15 1:57 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-03 6:40 [PATCH 1/4] zsmalloc: rename zspage_order with zspage_pages Minchan Kim
2012-05-03 6:40 ` [PATCH 2/4] zsmalloc: add/fix function comment Minchan Kim
2012-05-03 13:19 ` Nitin Gupta
2012-05-03 6:40 ` [PATCH 3/4] zsmalloc use zs_handle instead of void * Minchan Kim
2012-05-03 13:32 ` Nitin Gupta
2012-05-03 15:23 ` Seth Jennings
2012-05-04 2:24 ` Minchan Kim
2012-05-07 15:01 ` Seth Jennings
2012-05-09 20:19 ` Greg Kroah-Hartman
2012-05-10 2:03 ` Minchan Kim
2012-05-10 14:02 ` Konrad Rzeszutek Wilk
2012-05-10 14:12 ` Greg Kroah-Hartman
2012-05-10 14:47 ` Nitin Gupta
2012-05-10 15:00 ` Minchan Kim
2012-05-10 15:11 ` Seth Jennings
2012-05-10 15:19 ` Minchan Kim
2012-05-10 15:19 ` Greg Kroah-Hartman
2012-05-10 16:29 ` Nitin Gupta
2012-05-10 16:44 ` Greg Kroah-Hartman
2012-05-10 17:24 ` Nitin Gupta
2012-05-10 17:33 ` Konrad Rzeszutek Wilk
2012-05-10 23:24 ` Minchan Kim
2012-05-10 23:50 ` Dan Magenheimer
2012-05-11 0:14 ` Minchan Kim
2012-05-11 16:31 ` Dan Magenheimer
2012-05-11 19:29 ` Konrad Rzeszutek Wilk
2012-05-11 21:49 ` Seth Jennings
2012-05-14 2:26 ` Minchan Kim
2012-05-11 19:28 ` Konrad Rzeszutek Wilk
2012-05-14 2:18 ` Minchan Kim
2012-05-15 1:57 ` Nitin Gupta [this message]
2012-05-15 2:21 ` Minchan Kim
2012-05-15 15:04 ` Konrad Rzeszutek Wilk
2012-05-16 1:36 ` Minchan Kim
2012-05-16 11:06 ` Konrad Rzeszutek Wilk
2012-05-03 6:40 ` [PATCH 4/4] zsmalloc: zsmalloc: align cache line size Minchan Kim
2012-05-03 13:58 ` Nitin Gupta
2012-05-04 2:27 ` Minchan Kim
2012-05-07 7:41 ` Pekka Enberg
2012-05-07 12:40 ` Nitin Gupta
2012-05-08 1:34 ` Minchan Kim
2012-05-08 14:00 ` Dan Magenheimer
2012-05-09 0:58 ` Minchan Kim
2012-05-09 3:08 ` Dan Magenheimer
2012-05-09 4:07 ` Minchan Kim
2012-05-11 0:03 ` Dan Magenheimer
2012-05-11 0:25 ` Minchan Kim
2012-05-11 19:06 ` Konrad Rzeszutek Wilk
2012-05-14 1:55 ` Minchan Kim
2012-05-15 15:18 ` Konrad Rzeszutek Wilk
2012-05-16 1:44 ` Minchan Kim
2012-05-03 13:18 ` [PATCH 1/4] zsmalloc: rename zspage_order with zspage_pages Nitin Gupta
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=CAPkvG_dTA7HwzVBo70bZuqkX+ZfjJpS+p4L9L+jF4Uz1ooEx0Q@mail.gmail.com \
--to=ngupta@vflare.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).