lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <512271E1.9000105@linux.vnet.ibm.com>
Date:	Mon, 18 Feb 2013 12:24:33 -0600
From:	Seth Jennings <sjenning@...ux.vnet.ibm.com>
To:	Ric Mason <ric.masonn@...il.com>
CC:	Minchan Kim <minchan@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Nitin Gupta <ngupta@...are.org>,
	Dan Magenheimer <dan.magenheimer@...cle.com>,
	Konrad Rzeszutek Wilk <konrad@...nok.org>
Subject: Re: [PATCH] zsmalloc: Add Kconfig for enabling PTE method

On 02/16/2013 12:28 AM, Ric Mason wrote:
> On 02/04/2013 08:23 AM, Minchan Kim wrote:
>> Zsmalloc has two methods 1) copy-based and 2) pte based to access
>> allocations that span two pages.
>> You can see history why we supported two approach from [1].
>>
>> But it was bad choice that adding hard coding to select architecture
>> which want to use pte based method. This patch removed it and adds
>> new Kconfig to select the approach.
>>
>> This patch is based on next-20130202.
>>
>> [1] https://lkml.org/lkml/2012/7/11/58
>>
>> Cc: Andrew Morton <akpm@...ux-foundation.org>
>> Cc: Seth Jennings <sjenning@...ux.vnet.ibm.com>
>> Cc: Nitin Gupta <ngupta@...are.org>
>> Cc: Dan Magenheimer <dan.magenheimer@...cle.com>
>> Cc: Konrad Rzeszutek Wilk <konrad@...nok.org>
>> Signed-off-by: Minchan Kim <minchan@...nel.org>
>> ---
>>   drivers/staging/zsmalloc/Kconfig         |   12 ++++++++++++
>>   drivers/staging/zsmalloc/zsmalloc-main.c |   11 -----------
>>   2 files changed, 12 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/staging/zsmalloc/Kconfig
>> b/drivers/staging/zsmalloc/Kconfig
>> index 9084565..2359123 100644
>> --- a/drivers/staging/zsmalloc/Kconfig
>> +++ b/drivers/staging/zsmalloc/Kconfig
>> @@ -8,3 +8,15 @@ config ZSMALLOC
>>         non-standard allocator interface where a handle, not a
>> pointer, is
>>         returned by an alloc().  This handle must be mapped in order to
>>         access the allocated space.
>> +
>> +config ZSMALLOC_PGTABLE_MAPPING
>> +        bool "Use page table mapping to access allocations that
>> span two pages"
>> +        depends on ZSMALLOC
>> +        default n
>> +        help
>> +      By default, zsmalloc uses a copy-based object mapping method
>> to access
>> +      allocations that span two pages. However, if a particular
>> architecture
>> +      performs VM mapping faster than copying, then you should
>> select this.
>> +      This causes zsmalloc to use page table mapping rather than
>> copying
>> +      for object mapping. You can check speed with zsmalloc
>> benchmark[1].
>> +      [1] https://github.com/spartacus06/zsmalloc
> 
> Is there benchmark to test zcache? eg. internal fragmentation level ...

First, zsmalloc is not used in zcache right now so just wanted to say
that.  It is used in zram and the proposed zswap
(https://lwn.net/Articles/528817/)

There is not an official benchmark.  However anything that generates
activity that will hit the frontswap or cleancache hooks will do.
These are workloads that overcommit memory and use swap, or access
file sets whose size is larger that the system page cache.

The closest thing to a fragmentation metric is an effective
compression ratio that can be calculated with debugfs attributes:

zcache_[eph|pers]_zbytes / (zcache_[eph|pers]_pageframes * PAGE_SIZE)

eph for cleancache, and pers for frontswap.

Seth

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ