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

Re: initrd sizes mushroomed several months ago



On Sat 04 Feb 2023 at 18:04:21 (-0500), Felix Miata wrote:
> David Wright composed on 2023-02-04 10:59 (UTC-0600):
> 
> > I don't yet know which directories are being included in yours.
> 
> 6 instances of lsinitramfs, with and without -l for 3 kernels:
> 
> # initrd.img-5.17.0-1-amd64; gzip bytes:7,649,297; lines:445:
> https://termbin.com/2o3z https://paste.debian.net/1269679/
> https://termbin.com/alsd # verbose (-l) https://paste.debian.net/1269680/
> 
> # initrd.img-5.18.0-1-amd64; gzip bytes:34,289,103; lines:1132:
> https://termbin.com/7xzk https://paste.debian.net/1269681/
> https://termbin.com/nrp2 # verbose (-l) https://paste.debian.net/1269682/
> 
> # initrd.img-6.0.0-6-amd64; zstd bytes:26,414,992; lines:1196:
> https://paste.debian.net/1269676/
> https://paste.debian.net/1269677/ # verbose (-l)
> 
> Paste.debian.net wasn't working when I started.

So I noticed. When I looked for the files you pasted yesterday,
whois claimed that it didn't exist.

Summarising the above, I see:

          my        my
        system    system     initrd    initrd    initrd
        buster   bullseye     5.17      5.18      6.0

amdgpu   277        381        0        419       479
radeon   247        247        0        232       232

The reduction in firmware for radeon from the system to the firmware
consists of 15 items that have identical copies in amdgpu, which
suggests they might have been placed in radeon by mistake. (Items
with identical filenames under both directories are not necessarily
identical.)

OTOH new firmware is being included in the amdgpu directory, both
piecemeal (like adding picasso_ta.bin to bullseye) and in 'groups'
(like green_sardine_{asd,ce,dmcub,me,mec,mec2,pfp,rlc,sdma,ta,vcn}.bin),
so there's 72% more firmware in 6.0 than buster.

AFAICT inclusion in the initrd is by directory, so if one item from
amdgpu is required, then all 479 items in the directory are included
in a 6.0 initrd. This level of granularity, while adequate for most
devices, does seem to be an aspect that could do with improvement
as far as amdgpu and radeon are concerned.

The other problem for your initrds is that both the amdgpu and radeon
directories are being included, presumably because, according to your
dracut post, both the amdgpu.ko and radeon.ko modules are included
(and I think you implied they're not even necessary). Can you figure
out what the dracut initrd is replacing them with, if anything.

Cheers,
David.


Reply to: