2015-02-02 01:09:24

by Minchan Kim

[permalink] [raw]
Subject: Re: [PATCH] mm/zsmalloc: avoid unnecessary iteration when freeing size_class

Hello Ganesh,

On Sat, Jan 31, 2015 at 04:59:58PM +0800, Ganesh Mahendran wrote:
> ping.
>
> 2015-01-24 21:50 GMT+08:00 Ganesh Mahendran <[email protected]>:
> > The pool->size_class[i] is assigned with the i from (zs_size_classes - 1) to 0.
> > So if we failed in zs_create_pool(), we only need to iterate from (zs_size_classes - 1)
> > to i, instead of from 0 to (zs_size_classes - 1)
>
> No functionality has been changed. This patch just avoids some
> necessary iteration.

Sorry for the delay. Did you saw any performance problem?
I know it would be better than old but your assumption depends on the
implmentation of zs_create_pool so if we changes(for example,
revert 9eec4cd if compaction works well), your patch would be void.
If it's not a critical, I'd like to remain it as generic and doesn't
contaminate git-blame.

Thanks.

--
Kind regards,
Minchan Kim


2015-02-02 12:09:45

by Ganesh Mahendran

[permalink] [raw]
Subject: Re: [PATCH] mm/zsmalloc: avoid unnecessary iteration when freeing size_class

Hello Minchan:

2015-02-02 9:09 GMT+08:00 Minchan Kim <[email protected]>:
> Hello Ganesh,
>
> On Sat, Jan 31, 2015 at 04:59:58PM +0800, Ganesh Mahendran wrote:
>> ping.
>>
>> 2015-01-24 21:50 GMT+08:00 Ganesh Mahendran <[email protected]>:
>> > The pool->size_class[i] is assigned with the i from (zs_size_classes - 1) to 0.
>> > So if we failed in zs_create_pool(), we only need to iterate from (zs_size_classes - 1)
>> > to i, instead of from 0 to (zs_size_classes - 1)
>>
>> No functionality has been changed. This patch just avoids some
>> necessary iteration.
>
> Sorry for the delay. Did you saw any performance problem?
> I know it would be better than old but your assumption depends on the
> implmentation of zs_create_pool so if we changes(for example,
> revert 9eec4cd if compaction works well), your patch would be void.

Yes, You are right.
Thanks so much.

> If it's not a critical, I'd like to remain it as generic and doesn't
> contaminate git-blame.
>
> Thanks.
>
> --
> Kind regards,
> Minchan Kim