On 21/10/2022 16:07, Joel Sherrill wrote:
On Thu, Oct 20, 2022 at 7:30 PM Chris Johns <chr...@rtems.org
<mailto:chr...@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.hu...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
