On Sat, Dec 4, 2021 at 2:22 AM Ilya Maximets <i.maxim...@ovn.org> wrote: > > On 9/9/21 14:49, David Marchand wrote: > > On Fri, Aug 6, 2021 at 2:44 PM Rosemarie O'Riorden <rorio...@redhat.com> > > wrote: > >> > >> If anonymous memory mapping is supported by the kernel, it's better > >> to run OVS entirely in memory rather than creating shared data > >> structures. OVS doesn't work in multi-process mode, so there is no need > >> to litter a filesystem and experience random crashes due to old memory > >> chunks stored in re-opened files. > >> > >> When OVS is not running in memory and crashes, it never reaches the > >> clean up scripts that delete the new files it has created, resulting in > >> "dirty" memory. OVS will partially overwrite this memory on the next > >> start-up, but will fail to run again because its filesystem is full of > >> old memory. > >> > >> Here is an example of these crashes: > >> > >> https://inbox.dpdk.org/dev/20200910162407.12669-1-david.march...@redhat.com/ > > > > Overall, I am fine with this change. > > > > > > - In the commitlog, I would focus on the simplication aspect and that > > we only use what we need. > > Mention of this bug can be removed. > > The reason is that this is not as black/white as described: reusing > > dirty memory only happened in a special case with containers. > > But this does not affect OVS (I don't think we run OVS in containers). > > OK. I think, we can just put a period after the 'to litter a filesystem' > and remove everything else. That's enough for justification. WDYT?
+1 > > > > > > > - As mentionned by Ilya, MAP_HUGE_SHIFT is most likely supported on > > systems running current OVS. > > Can we remove the permissions tweak on /dev/hugepages in > > rhel/usr_lib_systemd_system_ovs-vswitchd.service.in ? > > (Cc: Timothy who might have an opinion on this). > > Since users could still put '--legcy-mem' into dpdk-extra, they might > still need filesystem access. So, I guess, we still need the tweaks. True. > We could, probably, forbid running with legacy-mem at some point in the > future though. > > Are there plans in DPDK to deprecate the legacy memory model someday? Hard to remove this mode in DPDK atm: FreeBSD does not implement the new mode. And the DPDK memory allocator beast has very few contributors, so I can't promise anything. -- David Marchand _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
