On Thu, 2021-09-30 at 23:32 +0800, heming.zhao@xxxxxxxx wrote: > > I just want to say that some of the issues might simply be > > regressions/issues with systemd/udev that could be fixed. We as > > providers of block device abstractions where we need to handle, > > sometimes, thousands of devices, might be the first ones to hit these > > issues. > > > > The rhel8 callgrind picture > (https://prajnoha.fedorapeople.org/bz1986158/rhel8_libudev_critical_cost.png > ) > responds to my analysis: > https://listman.redhat.com/archives/linux-lvm/2021-June/msg00022.html > handle_db_line took too much time and become the hotspot. I missed that post. You wrote > the dev_cache_scan doesn't have direct disk IOs, but libudev will scan/read > udev db which issue real disk IOs (location is /run/udev/data). > ... > 2. scans/reads udev db (/run/udev/data). may O(n) > udev will call device_read_db => handle_db_line to handle every > line of a db file. > ... > I didn't test the related udev code, and guess the <2> takes too much time. ... but note that /run/udev is on tmpfs, not on a real disk. So the accesses should be very fast unless there's some locking happening. Regards Martin _______________________________________________ linux-lvm mailing list linux-lvm@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
