<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 20, 2022 at 7:30 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 20/10/2022 7:01 pm, Sebastian Huber wrote:<br>
> On 29/08/2022 10:27, Sebastian Huber wrote:<br>
>> Hello Chris,<br>
>><br>
>> On 25/07/2022 08:12, Sebastian Huber wrote:<br>
>>> On 11/07/2022 15:04, Sebastian Huber wrote:<br>
>>>> On 24/06/2022 08:33, Sebastian Huber wrote:<br>
>>>>> This patch set removes the FreeBSD file descriptors.  The VFS is no longer<br>
>>>>> used<br>
>>>>> if only the USB, SD/MMC, network, PCI, and NVMe support is used by the<br>
>>>>> application.  This change significantly reduce the memory usage of LibBSD for<br>
>>>>> these applications.  Using the media01 test case for the arm/lpc32xx BSP as a<br>
>>>>> benchmark, the heap usage dropped from 14.3MiB to 10.2MiB.  The "_BSD<br>
>>>>> bufdaemon", "_BSD vnlru", "_BSD syncer", and "_BSD bufspacedaemon-" tasks are<br>
>>>>> no longer present in media01.  The code size is reduced by about 8KiB.  The<br>
>>>>> data size is reduced by about 30KiB.  The throughput with a simple FTP test<br>
>>>>> increased by about 1%.<br></blockquote><div><br></div><div>Only the decrease in heap size is significant enough to discuss. The others are noise</div><div>when considered in light of the source transparency we aimed for.<br><br><a href="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</a><br><br>This guideline which is intended to increase compatibility and lower long-term</div><div>maintenance is at odds with this set of patches.</div><div><br></div><div>That leaves us with the 4MB of heap. That alone is your problem. What is </div><div>allocating it? Is there a hint or sysctl value that can turn it down? Is it </div><div>representative of a single feature that could just be disabled in your</div><div>low memory situation [1].</div><div><br></div><div>[1] I agree with Chris' statements that there are no requirements for</div><div>a set of functionality to fit within a certain amount of memory. And </div><div>if you are this close to the edge, almost anything that happens will</div><div>break it again.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>>>>><br>
>>>>> The "Remove FreeBSD file descriptors" change removes more lines than there are<br>
>>>>> added.<br>
>>>>><br>
>>>>> This change makes it easier to port the NFS support to the master branch since<br>
>>>>> now the changes are more localized.<br>
>>>><br>
>>>> I have a target with only 8MiB of RAM (for code and data). So, this patch<br>
>>>> set is not just a micro optimization.<br>
>>><br>
>>> This pending patch set is currently a blocker for me. I would like to work on<br>
>>> the NTP daemon integration and an update of the libbsd master branch to a<br>
>>> more recent FreeBSD version. This patch set just restores what worked well<br>
>>> for several years.<br>
>><br>
>> did you have time to review this patch set in the meantime? The NTP client no<br>
>> longer crashes with this patch set.<br>
> <br>
> This patch set is now pending for about four months. From my point of view it is<br>
> a straight forward fix of some severe issues which prevent the use of libbsd on<br>
> lower end targets.<br>
<br>
Is there a repo somewhere with the patches applied? I am being lazy asking as I<br>
would like to avoid downloading the 22 patches and applying them by hand.<br>
<br>
It seems the media test cannot grow by more than 9K of code and the heap by 5M!<br>
Is my understanding correct? Anything else we need to understand about the low<br>
end limits?<br>
<br>
I have not seen any requirements on the lower end for libbsd before now. How do<br>
we manage the competing requirement of low end support and adding functionality<br>
to libbsd in the future if they clash?<br>
<br>
Adding VFS support as FreeBSD implements it has pushed you over the edge but<br>
that edge is not defined so it makes it difficult for anyone other than you to<br>
work on this code base in a major way. I was not aware this was an issue and for<br>
me the extra 9K of code is not a problem and a 5M change in heap is acceptable.<br></blockquote><div><br></div><div>Again that increased heap usage is clearly a memory allocation and there is code</div><div>which is doing it. Can it be disabled and we avoid this entire set of invasive patches?</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> It is not really good if our internal libbsd branches diverge<br>
> too much from the RTEMS mainline.<br>
<br>
Yes I agree. It is not in anyone's interest and that only benefits you.<br>
<br>
I would like to reiterate we have an obligation to maintain the code base as<br>
close to FreeBSD as possible. Some of these changes push that boundary. We need<br>
to find a suitable path forward.<br>
<br>
Reviewing the changes:<br>
<br>
1. The break up of the syscalls file. The related comments are:<br>
<br>
 "Collecting all system calls in a single translation unit is not good<br>
  due to the library initialization through linker sets."<br>
<br>
Could you please explain what the linker set issue is?<br>
<br>
Why the need to change FreeBSD calls to static? Is it solely a performance<br>
optimisation?<br>
<br>
We are required to use function and data sections so I assume the syscall file<br>
will be broken up by the linker where possible?<br>
<br>
I cannot tell from the patches if the conditional syscall trace support is still<br>
present?<br>
<br>
I do not agree with your statement in the patches separation helps porting. My<br>
experience was not that. When adding VFS and the NFS client I found the syscall<br>
code all over the place and not easy to find, hard to review and it added<br>
complexity. It adds unnecessary changes to the FreeBSD code against a base<br>
requirement of the porting effort.<br>
<br>
2. FreeBSD file descriptor removal<br>
<br>
Does this mean we can never have them in libbsd? Does that limit what can be<br>
brought across from FreeBSD in the future?<br>
<br>
3. select, poll, and kqueue<br>
<br>
Do these calls work with an NFS client fd?<br>
<br>
4. Types of RTEMS fd's in libbsd<br>
<br>
The change I made brought the types into a single location so it is easier to<br>
review and understand. There is:<br>
<br>
 - rtems_bsd_sysgen_dirops<br>
 - rtems_bsd_sysgen_fileops<br>
 - rtems_bsd_sysgen_nodeops<br>
 - rtems_bsd_sysgen_imfsnodeops<br>
<br>
VFS is now left to handle the specific vnode ops as FreeBSD is designed to do.<br>
<br>
[<br>
<a href="https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-bsd-syscall-api.c?h=6-freebsd-12" rel="noreferrer" target="_blank">https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-bsd-syscall-api.c?h=6-freebsd-12</a><br>
]<br>
<br>
Chris<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>