From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail5.wrs.com (mail5.windriver.com [192.103.53.11]) by mail.openembedded.org (Postfix) with ESMTP id 4DEA47CE12 for ; Wed, 21 Aug 2019 00:24:50 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail5.wrs.com (8.15.2/8.15.2) with ESMTPS id x7L0NXCI019115 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Aug 2019 17:23:44 -0700 Received: from soho-mhatle-m.local (172.25.36.226) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.468.0; Tue, 20 Aug 2019 17:23:23 -0700 To: Adrian Bunk References: <1566221602-123706-1-git-send-email-hongxu.jia@windriver.com> <28dbc362015c3cbae5b8550e8636e74802afbfc3.camel@linuxfoundation.org> <4cbf8a7b-f0b2-9a16-6a91-bead26ecef50@windriver.com> <20190820163841.GA24268@localhost> From: Mark Hatle Openpgp: preference=signencrypt Autocrypt: addr=mark.hatle@windriver.com; prefer-encrypt=mutual; keydata= mQENBFYKxFgBCACt/pzutBp6p/xVKTFJjHbM3KpQKCblyot/YP+bpTr51Hrc5xDXBQhoG7TC aIRvRIvbhEevEQK9y04gW3JK/5lobq5ORebolcsHlYBUvpNeIPjupLQwGvz/TPtrLRNGLqDC rvsM6OA2XbQ2bwzxWaSQS3ImE2O2iXOZn9HhThMGeDB4Nff3fgUvXOTDIrgWOn9K2DgLL7Yc zkUIlFdj+Nraksd/7BSk8oH6tjeBVhFqSFvKta9QxWgdr58oPaTYaW/xNqUjlLrbJuMw/MSe xzuYfdfDfm6J8kRjMOnwQ0n8svJElzqAk+d83ow38gpGQ+LkjGgnf8ZFJ4rUJFADroX3ABEB AAG0JU1hcmsgSGF0bGUgPG1hcmsuaGF0bGVAd2luZHJpdmVyLmNvbT6JATcEEwEIACEFAlYK xFgCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQfv796/r0vvlvZAf9Gs+eN320yhRW V/fZCsngKhmOK4v3HrTwFrkSmoD9QHQiE/5IPdNacHwIPwZx07tNBohB8xOeNqCPRYRBwGhA AnxKOPyd0nnm6ZhPzbA57v4x3IGRQr4QzvcBTASJq91l3Ew4lpAslyx5w1DPPqRD7G8ycDKg peKyDwmdkvCunVisSAQI3XIMq2y230biTO98tDPEezg+lg+yTsz9ZT33F5KNuWrpf8VL5fG/ mt+kAv7wtsx/KTRbqhH3iFXF6eBSwMjAfTXFlkLfbM9riJGXrWEl9n2S2R3cDHNHug0lb8f4 whK370KEO4OwRKIYW/VUBmzk5XZUE9DTlDSV8ycsrrkBDQRWCsRYAQgAwK3FuHCE+HW3YWdH PUjeSn5p//xJ57u8g2rng8zm9zNjmYgpPv5UxozaD9i2jf4mlQLHGGOezhHae8K4Nj70oVcv 8AmwcrJa9i9WL1oy/9R3fHMWf/Ctt9VXTO0qlCuq6PDzaUfvsXR61aJIjTKNQTOjCLjY1vXm VSewUgARysmA8WrjTfwGBihMBxAX0+kIjx8nOlam0WvekMBXZ0AbS56oTLRxYao6DI3GeB/N oWPy/5DfuTKaSdM0Pf8al20x9RuNN5/HLMlyDH/k8bIa1xd9aAqW+Feiw5gC107V2E6ULyIy q6em2UrsmIRxrvpHqbNgQKqvTehJ+V/i4g/uOwARAQABiQEfBBgBCAAJBQJWCsRYAhsMAAoJ EH7+/ev69L755XAH/3ZcNhooqd9OBhFkvXm1iWZ8EoC7motWqVn2oEyxoonsg8AD9kFXiN+T dYp7dH99EZu9q4ptj56AXm4uHzOgywL/5/V2TY6twCGAjUGzDjAB5gzoi+JLIBlDiyOip0eL QswIhRk473xy3j8DA4oVamnSPWgyNJ+qsdt37YWDzoDFFvtDoRU7Eb+znfIMDKzlny0XU/8L cW1bNHJlpv/78GPdfP4tjysEd8MuA5jf5o5w4XqcwTqalffEJtQ/s3pbkstEi7qm5uPui5Kt gq6YYLSqcSNe0GWAF9/T+qwyo7burSTxUWCWtMmlXdAQLW9SynLhB3Jbch0nFAh0fCKi6yY= Organization: Wind River Systems Message-ID: Date: Tue, 20 Aug 2019 19:23:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190820163841.GA24268@localhost> Cc: OE-core Subject: Re: [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 00:24:51 -0000 Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit On 8/20/19 11:38 AM, Adrian Bunk wrote: > On Tue, Aug 20, 2019 at 08:46:53AM -0500, Mark Hatle wrote: >> On 8/19/19 9:55 AM, richard.purdie@linuxfoundation.org wrote: >>> On Mon, 2019-08-19 at 16:01 +0200, Alexander Kanavin wrote: >>>> Should the limit be simply raised? The 256M setup is crumbling on >>>> several fronts (runtime tests, modernisation of X, various non-x86 >>>> qemu targets). Adding per-image/target exceptions, custom non- >>>> upstreamable patches, or sticking to deprecated configurations isn't >>>> the right thing to do, I think. >>> >>> What kind of devices/uses are we meant to be targeting? >>> >>> I believe OE is suited to optimised used cases where constraints on >>> size and performance are quite likely and supported. >>> >>> This is *exactly* the kind of thing we should be exploring and >>> supporting. systemd is not designed for some of the systems we target. >>> Changing some of its configuration shouldn't be a surprise. >>> >>> Having NFS taking up half the available memory doesn't make sense, >>> particularly when the sysvinit limits have worked for us for years. I >>> therefore appreciate Hongxu figuring out what the difference was and I >>> believe we should change this to something more suited for our target >>> audience, unless someone can explain why this is a bad idea. >>> >>> Similarly, forcing everyone to full GL stacks under qemu simply is not >>> acceptable. For example I might have a single container type image >>> which I want to load/test under qemu. Forcing such usage to require >>> 512MB memory for what could be a headless system also isn't right and >>> will just frustrate users. Users need to be able to access headless or >>> 2D configurations of it. >> >> Looking at what my customers are doing, I completely agree. I look at the >> design criteria for my customer's devices and I'm seeing 256MB as -very- common. >> More happens, but it's rare still. (But I have some customers with GB of ram, >> but that is usually to support their application, but the base system!) >> >> (Note, I do have customers -with- graphics requirements [X11] that are in the >> 128/256 MB ram ranges. In most cases OpenGL is something they would like, but I >> don't believe it's a hard requirement for them.) >> >> I do still have many customers with 128 MB of ram requirements. So it's >> important for us to set a reasonable baseline (256MB). So going under this >> requires 'work', but I think that is acceptable. > > There is also a certain disconnect between these numbers and the > constant pain for everyone of keeping everything building with > musl for small size gain. > > 128 MB RAM and 16 MB flash would be a configuration where I would not > worry about size enough to consider glibc a problem. > > Is there real-world demand for running X11 with musl? Size is only one reason for musl, the other is to have a non-GPL libc in the device. --Mark > Is there a CI setup ensuring that disk and RAM usage of relevant > musl setups don't regress - which might be more than the gains > of musl compared to glibc? > >> --Mark > > cu > Adrian >