From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75FDDC433F5 for ; Tue, 19 Oct 2021 13:04:20 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 12A1061360 for ; Tue, 19 Oct 2021 13:04:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 12A1061360 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4HYYq65MTzz307g for ; Wed, 20 Oct 2021 00:04:18 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=bCpjhUh1; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=chao@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=bCpjhUh1; dkim-atps=neutral Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4HYYq36wgNz2xrl for ; Wed, 20 Oct 2021 00:04:15 +1100 (AEDT) Received: by mail.kernel.org (Postfix) with ESMTPSA id DFD0C61372; Tue, 19 Oct 2021 13:04:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1634648653; bh=y4bwIP99bgP7Ml+JufuaLWJMSFCpFb2IgDQsVZrKASk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=bCpjhUh1VcXA9BupCXm2ZZIsAfA8v60rDCJCENAgyUd5lCl3+Xh1Qq5gGs02IAK4f HxvuxGpmjCgp6U260CCqlBEdvmMQu0PYJ71NGSLMwjx4ozStUNNQ9aTLCiFohPX8fc yLMbN8r33Bb2WrtgQgmkXvZJ1c7Aav2zZr+6JS/OdLRDgf8p+xnX0bFMOYuZrFXt+3 G25b1BglnnHmAu/ZOGUXw2sWnUd0vpIJ7gYzyNpN/aUnLaZtRD9oU5FuVjGCAFhX6x Tre/X9bbk+IWoVgQo+i5milRvsGdiEYeyAqoW5Kg9cqhW6dEgvjFVMCQk5SqRX8AAO wPMvlSz9YaD1A== Message-ID: Date: Tue, 19 Oct 2021 21:04:09 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH 7/7] erofs: lzma compression support Content-Language: en-US To: Gao Xiang , linux-erofs@lists.ozlabs.org, LKML References: <20211010213145.17462-1-xiang@kernel.org> <20211010213145.17462-8-xiang@kernel.org> From: Chao Yu In-Reply-To: <20211010213145.17462-8-xiang@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: linux-erofs@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Linux EROFS file system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Greg KH , Andrew Morton , Linus Torvalds , Lasse Collin , Gao Xiang Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" On 2021/10/11 5:31, Gao Xiang wrote: > From: Gao Xiang > > Add MicroLZMA support in order to maximize compression ratios for > specific scenarios. For example, it's useful for low-end embedded > boards and as a secondary algorithm in a file for specific access > patterns. > > MicroLZMA is a new container format for raw LZMA1, which was created > by Lasse Collin aiming to minimize old LZMA headers and get rid of > unnecessary EOPM (end of payload marker) as well as to enable > fixed-sized output compression, especially for 4KiB pclusters. > > Similar to LZ4, inplace I/O approach is used to minimize runtime > memory footprint when dealing with I/O. Overlapped decompression is > handled with 1) bounced buffer for data under processing or 2) extra > short-lived pages from the on-stack pagepool which will be shared in > the same read request (128KiB for example). > > Signed-off-by: Gao Xiang Acked-by: Chao Yu Thanks,