From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13819 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Nick Bray Newsgroups: gmane.linux.lib.musl.general Subject: Stdio resource usage Date: Tue, 19 Feb 2019 15:34:52 -0800 Message-ID: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000bff50c058247b052" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="31262"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-13835-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 20 00:35:19 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gwEv0-00081I-Pj for gllmg-musl@m.gmane.org; Wed, 20 Feb 2019 00:35:18 +0100 Original-Received: (qmail 22293 invoked by uid 550); 19 Feb 2019 23:35:16 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 22261 invoked from network); 19 Feb 2019 23:35:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+8rHIi98xLzyDI4glGDtEUxubRRFuI1g8FeMXsMqI1k=; b=VnWxuilWZLFpt//uW72h7qPqN3XhKUts7DqR8HISV3fCqNvTQbH3ns78GWytbhyWHr yNveafkOCivnXKP3Fg6MgnxSvFQ8EYYXU09PL1YOAe1P5CkeEpd+68+gZj57qKTzASSS GSzrF1OJx01CYk1uX1XC7Srmo/tKFuKFZx4euMYxHpWJo1dNcTJCrgMqvW99cIgaodGm 9Pvq7FpqGoidpealmMUaOAXB1cUoUU+Fggp+FW7jUQwZSndnjtBfZF2yTkf7+HI9dVXP WiwyRiqZ58GH+xnq7gWVGtIwnQxBrkk2f19j+z+Dv0ZDio5nGd65M9oCMhkwpvdzNBiK DkvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+8rHIi98xLzyDI4glGDtEUxubRRFuI1g8FeMXsMqI1k=; b=op9+3N281BJII+IgEezqxrLLoXtMreuRiJBhS/vFHqIidvty6btNjUqQiWzVNLWmyU RPeXyJKwMjW+Ov3U8ownz4lcBZIqgL76n53gTIhiCJKi/41qylc0KAPWOF2cCXvyIZta PuCDS9ZEuPyL/AwT+ooeI4Z1zOsaeESYRYK1EifTgjXZdOcHDqwjRFH23Z3tgP+WqTxt hxZ6/hZau2nvYbHM21c+PO6vL6A4CAJeQxnX+ttqvFKYN/ZaNnLf/MPW/xOcDYwF0kAs kRLv97QhEJV2bHXwNTLsQyYURmfuSzGGx88m7Q3wTYYbzrHeoYnS6Z+HtpZFe3zpUT2b H6/A== X-Gm-Message-State: AHQUAuY/JGNKG+AXxV6SsI82XmLq920bPvsk78b8teBuRg7GxJWRHYfI 8nUdiHqZnMb5LXnI/V33m8XMNyQTurF0ifyJUleDeQo3kbryqA== X-Google-Smtp-Source: AHgI3IZPtAZuiNDhB5pifZKp4EvKnXK+WfcMKhQAjkmb57gK7Lg0HDuXBJp/t5m9oyZUSeidW91U43qcqfvBMVJUi2k= X-Received: by 2002:a24:10c9:: with SMTP id 192mr4156207ity.34.1550619303185; Tue, 19 Feb 2019 15:35:03 -0800 (PST) Xref: news.gmane.org gmane.linux.lib.musl.general:13819 Archived-At: --000000000000bff50c058247b052 Content-Type: text/plain; charset="UTF-8" Other that compiler warnings, the main pain point I ran into porting a subset of Musl into a resource constrained environment was the resource usage of stdio. I don't expect any of these modifications to make it upstream. Talking out loud as a FYI / user feedback. Also curious to see if there's any wisdom out there. Stack usage of stdio was an issue. On arm64, printf takes 8k of stack which is a rough when you only have 4-12k of stack. This is because fmt_fp allocates stack space proportional O(log(MAX_LONG_DOUBLE)). It also gets inlined into printf so you always take the hit. (noinline fmt_fp is a Faustian bargain that makes stack usage worse in the worst case... hmmm.) On arm64, long double is defined as 128 bits, which not only increases stack size because of the larger mantisa, but also pulls in software emulation for fp128. In terms of spec compliance, Musl is doing the right thing. But as a practical matter, none of the programs I care about will ever use long double. So my rough first pass was to reduce the max float size from long double to double. In a later pass, I'll also add a knob to remove floating point formatting entirely. %m calls strerror which pulls in a string table, so removing support for %m lets static linking and DCE work its magic. I also eliminated %n for security hardening reasons. The "states" structure is sparse and takes a little more memory than I'd like - 464b of rodata. I don't see any workarounds without deeper changes, so for now I am living with it. --000000000000bff50c058247b052 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Other that compiler warnings, the ma= in pain point I ran into porting a subset of Musl into a resource constrain= ed environment was the resource usage of stdio.=C2=A0 I don't expect an= y of these modifications to make it upstream.=C2=A0 Talking out loud as a F= YI / user feedback.=C2=A0 Also curious to see if there's any wisdom out= there.

Stack usage of std= io was an issue.=C2=A0 On arm64, printf takes 8k of stack which is a rough = when you only have 4-12k of stack.=C2=A0 This is because fmt_fp allocates s= tack space proportional O(log(MAX_LONG_DOUBLE)).=C2=A0 It also gets inlined= into printf so you always take the hit.=C2=A0 (noinline fmt_fp is a Fausti= an bargain that makes stack usage worse in the worst case... hmmm.)=C2=A0 O= n arm64, long double is defined as 128 bits, which not only increases stack= size because of the larger mantisa, but also pulls in software emulation f= or fp128.=C2=A0 In terms of spec compliance, Musl is doing the right thing.= =C2=A0 But as a practical matter, none of the programs I care about will ev= er use long double.=C2=A0 So my rough first pass was to reduce the max floa= t size from long double to double.=C2=A0 In a later pass, I'll also add= a knob to remove floating point formatting entirely.

%m calls strerror which pulls in a string table, so removin= g support for %m lets static linking and DCE work its magic.=C2=A0 I also e= liminated %n for security hardening reasons.

The "states" structure is sparse and takes a little more m= emory than I'd like -=C2=A0 464b of rodata.=C2=A0 I don't see any w= orkarounds without deeper changes, so for now I am living with it.
--000000000000bff50c058247b052--