From: Alexander Dahl <ada@thorsis.com>
To: ptxdist@pengutronix.de
Cc: Michael Olbrich <m.olbrich@pengutronix.de>
Subject: Re: [ptxdist] systemctl daemon-reload fails
Date: Thu, 29 Oct 2020 09:33:37 +0100 [thread overview]
Message-ID: <1921819.ejFiOQ6pm9@ada> (raw)
In-Reply-To: <20201029080538.GU30556@pengutronix.de>
Hei hei,
Am Donnerstag, 29. Oktober 2020, 09:05:38 CET schrieb Michael Olbrich:
> On Thu, Oct 29, 2020 at 08:13:44AM +0100, Alexander Dahl wrote:
> > Am Mittwoch, 28. Oktober 2020, 18:40:58 CET schrieb Michael Olbrich:
…
> > > > On my target, it only has 64M of DRAM. After the kernel has reserved
> > > > its memory, only 55.5M is available for user space. It seems that /run
> > >
> > > Huh, I haven't used a system with less than 256M of SDRAM in a long
> > > time.
> > > I'm living in a different filter bubble... :-)
> >
> > For the record: we still work with boards designed ten years ago with 32
> > MiB RAM and run almost recent ptxdist and LTS kernel.
>
> Good to hear that.
>
> > I assume systemd +
> > additional dependencies (udev, dbus, …) would make those completly
> > unusable.
> So I played a bit with the qemu in DistroKit. I didn't even get any kernel
> output with 32M RAM....
> But it boots with 64M. And with just systemd, udev and journald running,
> about half the memory is still free, so that would be available for
> applications. And maybe 5-6M is used by those three processes, if I read
> the number correctly.
> The kernel is not trimmed for such low memory usage, so I think booting
> with 32M RAM with systemd might be possible, but the overhead is probably
> too much for real use-cases. But with 64M it should be fine.
We already actually have problems with applications eating up almost all the
memory. systemd and friends would be the straw breaking the camel's back. Our
kernel is trimmed down and we use initmethod-bbinit as you might have guessed.
>
> > Our new boards have 128 MiB though.
>
> Nothing with graphics i guess? I usually argue, that 512M is not enough...
> to run chromium :-).
What I work with or develop for are industrial communication gateways.
No graphics, no USB, some LEDs and a reset button are the only interfaces for
humans. ;-)
Greets
Alex
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de
prev parent reply other threads:[~2020-10-29 8:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-19 18:32 Jon Ringle
2020-10-19 18:36 ` Jon Ringle
2020-10-20 6:04 ` Ladislav Michl
2020-10-20 12:57 ` Jon Ringle
2020-10-21 7:27 ` Ladislav Michl
2020-10-28 7:28 ` Michael Olbrich
2020-10-28 7:37 ` Michael Olbrich
2020-10-28 13:27 ` Jon Ringle
2020-10-28 17:40 ` Michael Olbrich
2020-10-29 7:13 ` Alexander Dahl
2020-10-29 8:05 ` Michael Olbrich
2020-10-29 8:33 ` Alexander Dahl [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1921819.ejFiOQ6pm9@ada \
--to=ada@thorsis.com \
--cc=m.olbrich@pengutronix.de \
--cc=ptxdist@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox