09:01 <ardb> arnd: did the armhf 64k segment alignment issue ever get resolved?

09:12 <arnd> ardb: no. There was some interest to get a custom patch into debian, but I don't think it ever got merged

09:13 <ardb> i'm hitting this now after switching to a 16k kernel on my yoga c630

09:13 <ardb> this custom patch would be adding -Wl,-z,common-page-size=0x4000 to cflags for armhf?

09:14 <arnd> I think what I suggested was a revert of the binutils patch that changed the default, but the effect should be the same

09:15 <arnd> it used to be 0x10000, not 0x4000

09:15 <ardb> yeah but 16k should be sufficient i suppose

09:15 <ardb> given that debian provides a 16k kernel but not 64k

09:15 <ardb> that might make it more palatable in general

09:16 <ardb> although I suspect the -16k kernel package does not enable CONFIG_COMPAT at this point - we might want to change that too

09:16 <arnd> I'm pretty sure it does based on the earlier discussions

09:17 <arnd> debian kernels already have CONFIG_EXPERT enabled for some reason, and that meant that CONFIG_COMPAT never got turned off

09:17 <ardb> ah fair enough

09:17 <ardb> so the more reason to build armhf user space in a compatible fashion

09:17 <arnd> I think the binutils package is the same between Debian and Ubuntu, and the latter ships a 64K page kernel

09:21 <ardb> i was thinking it could simply be a dpkg build flag override

09:21 <arnd> There was an interesting side discussion about sparse object files: ld.bfd creates sparse files for aligning the sections, but .deb packages contain a non-sparse .tar file, and unpacking this leads to /usr/{bin,lib} also not having sparse files

09:23 <arnd> so the section alignment leads to higher disk usage, and filesystem readahead reads the extra zeroes into memory instead of using the common zero page

09:23 <ardb> another reason to prefer 16k over 64k

09:26 <arnd> sure, but fixing dpkg would also help arm64

09:26 <ukleinek> linusw__: oh, I remeber. I opened the company chat and then forgot what I wanted to send. SMP isn't for humans.

09:28 <arnd> The difference for the sparse files is fairly small. On my desktop I see with "du bin* lib* -sm" on two copies of each

09:28 <arnd> https://www.irccloud.com/pastebin/7rz1iFWH/

09:29 <arnd> so about 2% of /usr/lib

09:29 <arnd> 3.2% of /usr/bin

09:30 <ardb> yeah that seems worthwhile

09:31 <arnd> wait, I did this in tmpfs, which uses 16KB blocks, the difference shoudl be bigger on disk with 4KB blocks

09:33 <arnd> that's 11.3% for /usr/lib and 6.2% for /usr/bin

09:35 <ardb> wow

09:37 <arnd> I guess I can understand why binutils made the change to revert to 4KB pages, they correctly identified a problem, just came up with the wrong solution

09:41 <ardb> so will tar/untar generally do the right thing once you pass it the appropriate options?

09:45 <arnd> traditionally there were multiple incompatible extensions to store sparse files in a .tar file because the original implementation didn't do it. I'm fairly sure the default --sparse now works in a way that can be unpacked correctly and produce the exact same sparse blocks that the original had

09:46 <arnd> Not sure if there is a way to unpack long stretches of stored zeroes in existing archives into sparse files, or if we should do that in general

09:49 <arnd> apparently 'fallocate --dig-holes /usr/bin/*' is also a thing

09:54 <ardb> nice

09:55 <ardb> constructing the .debs with the appopriate metadata seems like a reasonable first step

21:17 <HdkR> Does PSCI collect statistics for how long a core is in WFE state that can be readback by the kernel?

21:22 <HdkR> Potentially PSCI_STAT_RESIDENCY?