[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Updated installer images 2020-12-02



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?


Reply to: