[libbsd 00/22] Remove FreeBSD file descriptors and avoid VFS
Sebastian Huber
sebastian.huber at embedded-brains.de
Fri Oct 21 14:16:49 UTC 2022
On 21/10/2022 16:07, Joel Sherrill wrote:
> On Thu, Oct 20, 2022 at 7:30 PM Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
>
> On 20/10/2022 7:01 pm, Sebastian Huber wrote:
> > On 29/08/2022 10:27, Sebastian Huber wrote:
> >> Hello Chris,
> >>
> >> On 25/07/2022 08:12, Sebastian Huber wrote:
> >>> On 11/07/2022 15:04, Sebastian Huber wrote:
> >>>> On 24/06/2022 08:33, Sebastian Huber wrote:
> >>>>> This patch set removes the FreeBSD file descriptors. The VFS
> is no longer
> >>>>> used
> >>>>> if only the USB, SD/MMC, network, PCI, and NVMe support is
> used by the
> >>>>> application. This change significantly reduce the memory
> usage of LibBSD for
> >>>>> these applications. Using the media01 test case for the
> arm/lpc32xx BSP as a
> >>>>> benchmark, the heap usage dropped from 14.3MiB to 10.2MiB.
> The "_BSD
> >>>>> bufdaemon", "_BSD vnlru", "_BSD syncer", and "_BSD
> bufspacedaemon-" tasks are
> >>>>> no longer present in media01. The code size is reduced by
> about 8KiB. The
> >>>>> data size is reduced by about 30KiB. The throughput with a
> simple FTP test
> >>>>> increased by about 1%.
>
>
> Only the decrease in heap size is significant enough to discuss. The
> others are noise
> when considered in light of the source transparency we aimed for.
>
> https://freebsdfoundation.org/wp-content/uploads/2016/08/FreeBSD-and-RTEMS-Unix-in-a-Real-Time-Operating-System.pdf <https://freebsdfoundation.org/wp-content/uploads/2016/08/FreeBSD-and-RTEMS-Unix-in-a-Real-Time-Operating-System.pdf>
>
> This guideline which is intended to increase compatibility and lower
> long-term
> maintenance is at odds with this set of patches.
It would be really nice if you could review the patch set in detail
before you write something like this. Did you ever update a FreeBSD
baseline in one of the libbsd branches? It is also a nice exercise to
step through for example sendto() from the file descriptor until you get
the socket object.
>
> That leaves us with the 4MB of heap. That alone is your problem. What is
> allocating it? Is there a hint or sysctl value that can turn it down? Is it
> representative of a single feature that could just be disabled in your
> low memory situation [1].
>
> [1] I agree with Chris' statements that there are no requirements for
> a set of functionality to fit within a certain amount of memory. And
> if you are this close to the edge, almost anything that happens will
> break it again.
With a clean constructor based initialization you can avoid a lot of
resource issues.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
More information about the devel
mailing list