[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56B2C4A7.6060106@intel.com>
Date: Thu, 4 Feb 2016 11:25:27 +0800
From: "Li, Weigang" <weigang.li@...el.com>
To: Joonsoo Kim <iamjoonsoo.kim@....com>,
Herbert Xu <herbert@...dor.apana.org.au>
CC: "David S. Miller" <davem@...emloft.net>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Minchan Kim <minchan@...nel.org>,
"Dan Streetman" <ddstreet@...e.org>,
<linux-crypto@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 04/10] crypto/compress: add asynchronous compression
support
On 2/1/2016 10:11 AM, Joonsoo Kim wrote:
> On Fri, Jan 29, 2016 at 06:09:01PM +0800, Herbert Xu wrote:
>> On Thu, Jan 28, 2016 at 12:19:42PM +0900, Joonsoo Kim wrote:
>>>
>>> I have tested asynchronous compression APIs in zram and I saw
>>> regression. Atomic allocation and setting up SG lists are culprit
>>> for this regression. Moreover, zram optimizes linearisation
>>
>> So which is it, atomic allocations or setting up SG lists? There
>> is nothing in acomp that requires you to do an atomic allocation.
>
> Atomic allocation are called for linearisation when needed. Zram's
> compressed content is usually stored in two physically separate pages
> so linearisation is needed. See scomp_map().
>
> Setting up SG lists means that to use acomp, sg_init_table(),
> sg_set_page() are need to be called by zram unlike the case just
> passing the pointer based buffer.
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hello Herbert & Joonsoo,
Please can you advise how to get the acomp patch accepted?
Powered by blists - more mailing lists