On Sun, 3 Jan 2021, Eero Tamminen wrote: > ... > * While kernel runs init a minute after being > booted [1], installer is *much* slower. > > E.g. after pressing Enter to select another > country, it takes 5-10 mins until installer > presents me with a list from which I can select > Europe >
Is that a kernel regression or an installer regression? > ... > Testing things this far took at least hour for > each run, due to installer slowness. Does anybody > happen to have an already installed minimal and up > to date Debian m68k disk image? > You may want to try to debootstrap one. ISTR there are instructions on wiki.debian.org. > > [1] Hatari profiler shows kernel CPU usage to go > in boot, until first sbrk() system call, to: > ------------------------------------------------ > Executed instructions: > 19.16% 25366973 memset > 7.97% 10548067 memcpy > 3.31% 4379652 _parse_integer > 1.88% 2489653 bit_putcs > 1.85% 2452344 link_path_walk > 1.82% 2406272 atafb_mfb_linefill > 1.26% 1672580 memmap_init_zone > 1.26% 1664687 timekeeping_advance > 1.10% 1452290 strlen > 1.07% 1422344 get_page_from_freelist > 1.05% 1388376 psi_group_change.constprop.0 > 0.94% 1240372 kmem_cache_alloc > 0.71% 936593 add_interrupt_randomness > 0.69% 909479 __d_lookup_rcu > 0.68% 896967 __ashldi3 > 0.64% 849576 atafb_imageblit > 0.62% 822723 kernfs_name_hash > 0.62% 820971 __list_add_valid > 0.54% 708561 notify_change > 0.51% 679840 __free_one_page > ------------------------------------------------ > > In cycles, memcpy() uses a bit more compared to > memset(), but memset() still takes most CPU. > > Attached are partial callgraphs showing where > they're most called from. Percentages in the > arrow lines indicate each function node's share > of those calls. > If this is a new phenomenon, git bisect may reveal what changed. Could the memcpy calls be related to 64-bit timekeeping?
