From:   Nick Terrell <terrelln@fb.com>
To:     Masahiro Yamada <masahiroy@kernel.org>
CC:     "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>,
        Michael Forney <forney@google.com>,
        Michal Marek <michal.lkml@markovi.net>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Ingo Molnar <mingo@kernel.org>,
        Sedat Dilek <sedat.dilek@gmail.com>,
        Kees Cook <keescook@chromium.org>,
        "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] kbuild: pass --stream-size --no-content-size to
 zstd
Thread-Topic: [PATCH v2 2/2] kbuild: pass --stream-size --no-content-size to
 zstd
Thread-Index: AQHX4UhKidKPr3kbgE2o2YP10PuuiKwkkw+AgAFMjIA=
Date:   Mon, 6 Dec 2021 18:42:57 +0000
Message-ID: <F49C6875-FFDD-4314-A202-0C428B525A6A@fb.com>
References: <20211124153105.155739-1-alex_y_xu@yahoo.ca>
 <20211124153105.155739-2-alex_y_xu@yahoo.ca>
 <CAK7LNASO_EmCp2zR_sBq_YNiw83Px8pKhcW78HKv1My7eKB+2w@mail.gmail.com>
In-Reply-To: <CAK7LNASO_EmCp2zR_sBq_YNiw83Px8pKhcW78HKv1My7eKB+2w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?IbZgJtL+SotSSm4NIigua96IL9+XU/QTw8cAaUspy1FtxtE+CpGEUASpdUb0?=
 =?us-ascii?Q?sJsgH1UpbFxzfzZdlm4XW1oIxj/c8Z/JpdRcRLtjPAKJtkV7fAg6ZUj8v9Pp?=
 =?us-ascii?Q?YyY4r9qo+Wz1tp4QCb9ja3JyzdudebLad1rTv25W02qgEVkBCK2bhDgqCJ3x?=
 =?us-ascii?Q?yVcYEmAmrtlSFwqJk0UkvpN78X49AkMoNqKwlpFLVS0Yqz2uOS0c0moeEMrX?=
 =?us-ascii?Q?AOrJB8JRTPHQAyqy9XlQPku3gdUHA+2C77QjYX+Ic7RrMWpui4e6t4eXbiu1?=
 =?us-ascii?Q?b46I3cEDqJr67WNQWC4k4I/821cblROBJXzNnEeAi3YxGwXIs/cE0tu3KmJP?=
 =?us-ascii?Q?Pj5cK3UUkoVN6PZoBtMDoYec8R/H3eli5NwSbjxiSJeamy96MGr/gzuR4ASb?=
 =?us-ascii?Q?WBLuGoHYCBMdrYbqkRz4Owwr84wfhkr55esMPCRbhCULrZp8O1h5RYGVc+PF?=
 =?us-ascii?Q?+0xpNcLJSl+fn7GeKlZIDw+0N+HJ0mlUgL8Sq5AF+N6pzKwMxHW+agW91Bfz?=
 =?us-ascii?Q?wCibrZBFDDkrus0iPKjNV4KR3tkZxc3glFbOD8WAQmAJ6NEmqEGIF86OSEr6?=
 =?us-ascii?Q?q2StmJ/x0EGT0X3tkf3EjGjd5JLd+1IlgVKpt1pXv6UF1n1nXg/xkzlecYWa?=
 =?us-ascii?Q?DK50P/ScoumYi2KMMIniTFX4CDpVbFebR03BW85E7KgQ+AIbH6Y7F5HFJDj4?=
 =?us-ascii?Q?HVZsz326e5N6IpZqoPF2Mw1/PSwpzraemStgLWY6345a0M0yzL1WpKGGxrq7?=
 =?us-ascii?Q?J/qX8SwsXw5mPHycrI5wf7po9KWl0WlyRYHae9/3Zmy9MXY5fJxxMKb3aGWy?=
 =?us-ascii?Q?bm+hqm0/qu0QgYaYWL9ck2j1mOB43E/lc7XZiqDMbXEZbJylglPOCBTD2Ypl?=
 =?us-ascii?Q?ZbpNZA2RvVKxgmfsjrZXCR/Sy17tJtfTMOE/iEU+PcnUgoy2hhT34jWE6xCJ?=
 =?us-ascii?Q?3opdN/DKMFhDS1FBtu53m/sYJzdjEkeOi06PQz0n95OItnkT4bukAmMZYMIk?=
 =?us-ascii?Q?U+ptBVlk6LMg1WHuZvBVFgOfOCNOWhm89u3i0TnPBpGBcA6hF9yfNlESp3h5?=
 =?us-ascii?Q?UOwtIg30bGwF9OVVMQIB79wbzYB680LzIDullfs7taeIXI4p9F0DbYkybZT7?=
 =?us-ascii?Q?jEqn8pQ4PgdPvncs595GqSqqLfE6U7kw3jHbvvzINt7RovYDyiDfxs4RSxO3?=
 =?us-ascii?Q?Ef02ElELdxAswrShwUP8UUMdSKEUo0Il1S79pMnLE7yWIo37BqBoxMu2vQLQ?=
 =?us-ascii?Q?dvzkF8R5ouZCgkEsdup8y0KZgj7fBmmPUcHXNIT2IYvSZoYZsZVyO1z3IetT?=
 =?us-ascii?Q?RNBeFTauf3UO3zjf/aauJFQfWY2O9/jK/SoqVOdnoeSxVylskvg7RVMvB+5g?=
 =?us-ascii?Q?i4WcxXcXcCkabVrkfS+8TkdBf7sAlI0058sJiU+fPcP8kqtH8WuWgVy7+P9G?=
 =?us-ascii?Q?27GKIOoTv3BwFw2BE80SPQ1WzVc5Fdv+oiL/I8mss3s30ioX9UA+Ps+fmG/t?=
 =?us-ascii?Q?iYB+6rlw11S0v2PZFNb6ZuPUzhHmZdb6aEdknfXqrQHVxEH5m7b14PZu5dRI?=
 =?us-ascii?Q?LlL4r26ZWiIoOhQQt2w=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5C371F601D27E84B9FDB758ACFB85FF1@namprd15.prod.outlook.com>
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR15MB3667.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 68d0ddbc-654e-4501-8f38-08d9b8e83919
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2021 18:42:57.8442
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: nP9SLovl4uuhISZ14JkLYzEoX0DgiOgi4jYDRSJ8sRt5tfNxZHeidbgpyvxMNQ2Z
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR15MB3620
X-OriginatorOrg: fb.com
X-Proofpoint-ORIG-GUID: nWXTKUejND0PqCs0GWRKTEFOA2VlB3eE
X-Proofpoint-GUID: nWXTKUejND0PqCs0GWRKTEFOA2VlB3eE
X-Proofpoint-UnRewURL: 0 URL was un-rewritten
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.11.62.513
 definitions=2021-12-06_07,2021-12-06_02,2021-12-02_01
X-Proofpoint-Spam-Details: rule=fb_outbound_notspam policy=fb_outbound score=0 clxscore=1015
 priorityscore=1501 mlxscore=0 malwarescore=0 phishscore=0 bulkscore=0
 lowpriorityscore=0 impostorscore=0 mlxlogscore=999 adultscore=0
 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2110150000 definitions=main-2112060112
X-FB-Internal: deliver
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Dec 5, 2021, at 2:52 PM, Masahiro Yamada <masahiroy@kernel.org> wrote:
> 
> On Thu, Nov 25, 2021 at 12:30 AM Alex Xu (Hello71) <alex_y_xu@yahoo.ca> wrote:
>> 
>> Otherwise, it allocates 2 GB of memory at once. Even though the majority
>> of this memory is never touched, the default heuristic overcommit
>> refuses this request if less than 2 GB of RAM+swap is currently
>> available. This results in "zstd: error 11 : Allocation error : not
>> enough memory" and the kernel failing to build.
>> 
>> When the size is specified, zstd will reduce the memory request
>> appropriately. For typical kernel sizes of ~32 MB, the largest mmap
>> request will be reduced to 512 MB, which will succeed on all but the
>> smallest devices.
>> 
>> For inputs around this size, --stream-size --no-content-size may
>> slightly decrease the compressed size, or slightly increase it:
>> https://github.com/facebook/zstd/issues/2848.
>> 
>> Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
> 
> 
> 
> 
> The reason why we need this workaround is just because we do
> "cat and compress".  zstd must allocate a huge memory beforehand
> since it cannot predict how long the stream it will receive.
> 
> If zstd is given with a file name, it can fstat it to know its file size
> and allocate the minimal amount of memory.
> 
> 
> This is my test.
> I used 'ulimit' to set the upper limit of the memory the zstd can use.
> 
> 
> [test steps]
> 
>  # Create a 1kB file
>  $ truncate --size=1k dummy
> 
>  # Set the memory size limit to 10MB
>  $ ulimit -S -v 10240
> 
>  # Pass the file as a argument; success
>  $ zstd -19 -o dummy.zst dummy
>  dummy                :  2.15%   (  1024 =>     22 bytes, dummy.zst)
> 
>  # cat and zstd; fail
>  $ cat dummy | zstd -19 > dummy.zst
>  zstd: error 11 : Allocation error : not enough memory
> 
>  # cat and zstd --stream-size; success
>  $ cat dummy | zstd -19 --stream-size=1024 > dummy.zst
> 
> 
> 
> 
> scripts/Makefile.modinst was written in such a way
> that zstd can know the file size by itself.
> 
>      cmd_zstd = $(ZSTD) -T0 --rm -f -q $<
> 
> 
> We cannot rewrite scripts/Makefile.lib in that way because
> arch/x86/boot/compress/Makefile concatenates two files before
> compression. And this is the only use-case of this feature.
> 
> So, I am seriously considering to revert this commit:
> 
> commit d3dd3b5a29bb9582957451531fed461628dfc834
> Author: H. Peter Anvin <hpa@zytor.com>
> Date:   Tue May 5 21:17:15 2009 -0700
> 
>    kbuild: allow compressors (gzip, bzip2, lzma) to take multiple inputs
> 
> 
> 
> 
> With that commit reverted, zstd will take a single input file,
> and we can do "zstd -o <output> <input>".
> 
> 
> So, I will take some time to investigate that approach.

This will definitely work from a zstd perspective. All versions
of zstd will downsize their memory usage to match the file size.

Best,
Nick Terrell

>> ---
>> scripts/Makefile.lib | 12 ++++++++++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>> 
>> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
>> index ca901814986a..c98a82ca38e6 100644
>> --- a/scripts/Makefile.lib
>> +++ b/scripts/Makefile.lib
>> @@ -466,12 +466,20 @@ quiet_cmd_xzmisc = XZMISC  $@
>> # single pass, so zstd doesn't need to allocate a window buffer. When streaming
>> # decompression is used, like initramfs decompression, zstd22 should likely not
>> # be used because it would require zstd to allocate a 128 MB buffer.
>> +#
>> +# --stream-size to reduce zstd memory usage (otherwise zstd -22 --ultra
>> +# allocates, but does not use, 2 GB) and potentially improve compression.
>> +#
>> +# --no-content-size to save three bytes which we do not use (we use size_append).
>> +
>> +# zstd --stream-size is only supported since 1.4.4
>> +zstd_stream_size = $(shell $(ZSTD) -1c --stream-size=0 --no-content-size </dev/null >/dev/null 2>&1 && printf '%s' '--stream-size=$(total_size) --no-content-size')
>> 
>> quiet_cmd_zstd = ZSTD    $@
>> -      cmd_zstd = { cat $(real-prereqs) | $(ZSTD) -19; $(size_append); } > $@
>> +      cmd_zstd = { cat $(real-prereqs) | $(ZSTD) $(zstd_stream_size) -19; $(size_append); } > $@
>> 
>> quiet_cmd_zstd22 = ZSTD22  $@
>> -      cmd_zstd22 = { cat $(real-prereqs) | $(ZSTD) -22 --ultra; $(size_append); } > $@
>> +      cmd_zstd22 = { cat $(real-prereqs) | $(ZSTD) $(zstd_stream_size) -22 --ultra; $(size_append); } > $@
>> 
>> # ASM offsets
>> # ---------------------------------------------------------------------------
>> --
>> 2.34.0
>> 
> 
> 
> -- 
> Best Regards
> Masahiro Yamada