marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | Not ready for end users / self contained install yet. Soon. | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
<Glanzmann>
kov: When you change anything in the partitioning through macos, the partition numbers will be ordered in the order they're on the disk. So if you use the debian installer or parted to create the paritions and later change something in macos (including reinstalling the stub) the partitions will be reordered.
<Glanzmann>
kov: However other than a new parition number won't happen. If you create the partitions for Linux using diskutil in macos the order will not change since it is alread in order.
<Glanzmann>
jmr2 / David[m]123456789: Or just open a shell in macos and type 'id'.
<Glanzmann>
But i agree with jmr2, that is not your username.
eroux has joined #asahi
sirn- has joined #asahi
<Glanzmann>
I just had my first real power loss on the mini. Guess the electronic heater, electric kettle and coffee machine was a little bit to much for the fuse. No data loss. ;-)
<rkjnsn>
It lets you open any browser-supported file in the browser itself, regardless of the server-sent mime type or content disposition.
<rkjnsn>
Great for quickly looking at PDF files that try to force you to download them, as well as viewing files that you know are plain text but the browser doesn't.
<Glanzmann>
rkjnsn: The 300-600 IOPS thingy is that with the new tree from axboe?
<Glanzmann>
I don't really care, because I'll work with the flush every second or minute mode.
<Glanzmann>
If I had done more research earlier, I had used that for months by now.
s1gtrap[m] has joined #asahi
<Glanzmann>
But that is becase I use it mainly as a workstation, and I have all my data on remote systems, so I don't care if I loose a second. Also I have a battery ...
eroux_ has joined #asahi
eroux has quit [Ping timeout: 480 seconds]
Misthios has quit [Quit: Ping timeout (120 seconds)]
Misthios has joined #asahi
<rkjnsn>
That was on macOS using F_BARRIERFSYNC instead of F_FULLFSYNC. If I understand correctly (which it sounds like maybe I don't…), whereas F_FULLFSYNC ensures the data is written to persistent storage F_BARRIERFSYNC, merely ensures that the data written before the sync hits persistent storage before data written after it, but it is still not guaranteed to be written when the call returns. My thinking was that if the underlying functionality used by
<rkjnsn>
F_BARRIERFSYNC was used for fsync instead of doing a flush, it could hopefully ensure that users of fsync would be guaranteed internal consistency of whatever made it to disk, even if there was the possibility for lost writes.
<Glanzmann>
marcan: What is on your todo list before the first release?
<marcan>
kernel tree cleanup, distro work, installer, maybe look at the SPMI driver a bit but it's not critical
<Glanzmann>
I see, nice.
<Glanzmann>
Thanks to your rtc patch it is much more pleasent to install Debian, tested it yesterday with the latest spmi branch from jannau. Works pretty good.
<Glanzmann>
The debian installer itself uses 'ntpdate' so that is not the issue, but once the fresh debian is installed, it had the wrong date and no ntpdate, so it was difficult to install new packages, but with the rtc that is now easy.
sri has joined #asahi
eroux_ has quit []
willemml has quit [Quit: willemml]
sri has quit [Quit: Leaving]
psykose has quit [Remote host closed the connection]
psykose has joined #asahi
eroux has joined #asahi
<j`ey>
Glanzmann: if you missed it, the new asahi branch is out
<mps>
big diff in t8103.dtsi in current asahi branch and jannau's u-boot, but lets try
<mps>
booted on MBP, sound card is missing
<mps>
apple-mca 238400000.mca: no tx0a DMA channel: 0
<Glanzmann>
j`ey: Thank you. I was afk, but I'll test it immediately.
<j`ey>
is scaling_cur_freq the right sysfs file to look at for current frequency?
<mps>
povik: yes, with syncing t8103.dtsi from kernel with u-boot audio card works, sorry again for false alarm
<povik>
great, np
<Glanzmann>
kettenis: Does this branch have the PCI for the mini for usb a ports?
<kettenis>
that now has the DTs fully sunched with the asahi kernel branch
<kettenis>
no
<Glanzmann>
j`ey: I tried power-off on the new asahi tree, it works on air.
<j`ey>
Glanzmann: cool, I realised it was SPMI it relied on (which I had left disabled for now)
<Glanzmann>
j`ey: Yep, that is what I spend a whole day on after marcan released rtc/reboot/power-off and janau did the missing device trees for t8103 devices.
<kettenis>
note that now that the device trees are in sync, there is no downside of using the kernel DTs from the asahi kernel branch instead of the ones from u-boot
<Glanzmann>
kettenis: Perfect. My build scripts do it that way.
<kettenis>
for that reason I didn't even bother adding the t600x DTs
<j`ey>
cool poweroff working, with no change in size to the kernel, i guess it all fitted in some padding/alignment
<axboe>
povik: man, that's a counter intuitive way to define LAST
<axboe>
idiomatic way is usually to have FOO_NR, where FOO_NR is indeed last-valid + 1
<axboe>
would also clean up those weird <= loops
<axboe>
(not your fault, looks like an alsa oddity)
<tpw_rules>
axboe: you have an m1 pro though don't you? and what are you compiling?
<axboe>
tpw_rules: yep pro with 6 p cores, just compiling my for-next release kernel that I use in qemu for local testing
<tpw_rules>
oh, huh. i got about 25% slower on the regular m1 mini. but for some reason once or twice it was only 10% slower
<axboe>
tpw_rules: that's huge - since my compile is not that big, linking is probably skewing the numbers on my side in terms of raw compile speed differences
<tpw_rules>
yeah, mine was for a full distro kernel type build. 20 vs 25 mins
<kettenis>
povik: we still nedd a way to express the speaker layout on the laptops in the device tree
<mps>
also I have slowdown about 20-25% when building kernel, but on some other things it as around 10%
<axboe>
I'll try a bigger compile, but that just makes the 16k page size even more compelling
<tpw_rules>
yeah it really is
<axboe>
mps: what's the baseline time for the kernel build you are doing?
<axboe>
mine is small enough that it's around 85s for the whole thing
<tpw_rules>
(also it still takes nixos's infrastructure >1hr to compile)
<mps>
axboe: I have enabled a lot of drivers as modules
<mps>
on 16K it builds in about 4 minutes and few seconds, and on 4K it is about 6 minutes
<tpw_rules>
kettenis: does your u-boot asahi branch have all the same stuff as the old m1-m1n1-nvme one?
<mps>
that is on earlier kernels, without your flush patch
<tpw_rules>
i did my builds in a tmpfs fwiw
<axboe>
mps: massive difference indeed
<kettenis>
tpw_rules: no, pcie support is missing
<tpw_rules>
so nvme will not work?
<kettenis>
nvme will work
<kettenis>
the type-A ports on the mini will no longer work
<tpw_rules>
ah, ok.
<jannau>
kcbench was 10% slower with 4k pages on my 10 core m1 max, doing 21-23 build per hour, so 2.5 to 3 minutes per build (iirc all cores at 2 Ghz)
<axboe>
timing allmodconfig, let's see how big of a difference it is here with all the crap enabled
<tpw_rules>
how is t600x support?
<tpw_rules>
are there device trees for that in u-boot now?
<kettenis>
t600x works; just use the asahi linux device trees now
<Glanzmann>
povik: Should I reboot?
<jannau>
tpw_rules: no, but you can use the dtbs from the kernel
<jannau>
requires current m1n1 and kernel
<tpw_rules>
hm ok, i'm not quite set up to do that yet
<Glanzmann>
jannau / j`ey / marcan: If you have a air hooked up to the mini, is it possible to issue reset using some magic thing?
<tpw_rules>
Glanzmann: you can type `reboot` into the hypervisor console
<Glanzmann>
povik: I don't know if you do, but you could run the kernel in the hypervisor, than you can reboot without my help.
myon98 has quit [Ping timeout: 480 seconds]
<povik>
kettenis: i guess we do. i am closing in on bringing the laptop speakers up
<povik>
i don't know how alsa knows which channel is which when #channels > 2
<povik>
but that actually isn't relevant here, is it :)
<sven>
you can also use macvdmtool
<sven>
or write patches for the tps code to be able to issue the magic USB PD commands from Linux
<povik>
macvdmtool is macos only, right?
<kettenis>
povik: my understanding that the canonical order is left right
<sven>
yes, but it shouldn’t be too hard to add support to the tipd driver in the kernel
<povik>
mine too :)
<sven>
macvdmtool essentially accesses some of the registers
<sven>
you just need to do that from linux
<sven>
The harder part is figuring out how to do that in a sane way so that it can be upstreamed ;)
<povik>
kettenis: left right, but beyond that point i don't know
<povik>
btw i can't bring up the laptop speakers with simple-audio-card or audio-graph-card as they are
<povik>
the linux drivers are limited and the bindings are limiting too, i think
<povik>
so my plan is to do something with compatible="apple,macaudio"
<povik>
and post that as an RFC
<povik>
if there is special compatible for the mac's audio cards, then the order of speakers can be fixed i guess
<povik>
meaning for a given amount of speakers, a specific layout is assumed and the speakers are placed in the layout based on their order in some sound-dai= list
<kettenis>
to me, the right approach would be to actually add a label to the tas5770l codecs to indicate their position
<povik>
interesting, to me the right approach is to keep that with the sound card, not the codec
<povik>
because the codec driver doesn't care
<povik>
but on the other hand the devicetrees are supposed to describe hardware, not drivers, i guess
<kettenis>
well, I think or OpenBSD I would like to use the stereo downmix capability of the tas5770l
<povik>
i would assume there's some prior art on this
<kettenis>
stranegly it seems there isn't
<kettenis>
and even if the codec itself wouldn't look at it, the higher level stuff could
<povik>
sure
<povik>
i should do the RFC for other reasons beyond the binding, and doing it with the fixed speaker order initially is easiest
<povik>
so i propose i go ahead with it and we discuss the binding on the list
<povik>
sounds good?
<kettenis>
sure
<kettenis>
just make sure you CC me as I'm not on any of the linux audio lists
<povik>
that goes without saying
<Glanzmann>
sven: I see (about macvdmtool). I thought there was also a tool for Linux.
<sven>
not for two connected m1s
<tpw_rules>
man i just have some kind of talent for finding u-boot and keyboard problems
<Glanzmann>
tpw_rules: I also have some keychron keyboard which does not work with u-boot.
<tpw_rules>
that sounds fancy and gamey?
<Glanzmann>
tpw_rules: I was looking for a clicky keyboard that is low. That is why I bought it and I like it.
<povik>
still i don't know why it doesn't manifest for me
<povik>
could gcc and clang be laying out structures in memory differently?
<Glanzmann>
But I also have some thinkpad usb keyboards with trackpoint I also like them a lot mainly due to the trackpoint.
<tpw_rules>
Glanzmann: sorry, that wasn't a criticism. a lot of those fancy gaming keyboards use a different usb protocol. does it have a "bios mode" or something?
<kov>
Glanzmann, same - I do that for the air keyboard as well
<Glanzmann>
kov: Me, too. But what I did not manage at the moment on the air is that I can switch option and command key and at the same time to be able to type german umlauts by doing right alt + a u ...
<tpw_rules>
what was the other sound patch?
<Glanzmann>
If you ever figure out how to do that, let me know.
<Glanzmann>
tpw_rules: pushed the m1-debian repository.
<kov>
Glanzmann, hmm how did you switch command and option? I used gnome's tweak tool to selected that 'alt and win are swapped' option and I seem to be able to use the right-side option key for the special characters option + s => ß
<Glanzmann>
No comes the hard part and talk marcan and to pulling them into linux-next. :-)
<kov>
(I use the us intl with dead keys layout)
<Glanzmann>
kov: I see, I purely use xorg config, since I'm running fvwm2.
<Glanzmann>
kov: All my keyboards are also us intl since 20 years.
<kov>
I wonder how tweak does it, I suppose it's libinput settings, but I know very little about this (more than I wanted to know already)
<Glanzmann>
mps: I should always ask you, we have such a similiar setup. :-)
<mps>
Fn is control and control is fn
<mps>
Glanzmann: I had this similarly on an old intel macbook
<kov>
mps, hah nice, I didn't know there was an option to switch fn and control
<tpw_rules>
kov: so that patch was applied, but the people at the bottom had criticisms?
<tpw_rules>
ftr i strongly disagree with Zan Dobersek there.
<kov>
and having opt/command as parameters to the module will be much better than using the tweaks trick ;D
<kov>
tpw_rules, yes! it's been applied and in theory has already been pulled into the stable branch as well
<mps>
I use this setup with awesome wm, and I have two left-alt keys, lazy to assign one of them for something useful :)
<kov>
tpw_rules, yeah, I'm writing a comment about that idea of building specifically for M1, let me know if you want me to relay anything
<tpw_rules>
kov: i mean basically i want to relay that the idea of having default binaries that break on M1 makes me sad. if you want to have a tweak to set it back to 4k if you want max performance or whatever and are building it yourself, then i suppose that's okay
<sven>
looks like the cable is constantly reconnected for some reason
<kov>
tpw_rules, basically because they no longer needed it for RHEL and users were seeing it and enabling it without understanding what they were doing heh https://bugs.webkit.org/show_bug.cgi?id=227905
<kov>
in the end the change stuck, there was a fix for the crash
<povik>
the other side is running macos, maybe it's trying to achieve something there
<Glanzmann>
sven: I see, thanks.
<tpw_rules>
kov: isn't that ever the case...
<sven>
ohh… maybe it’s trying to negotiate a thunderbolt connection?
<sven>
and then things go horribly wrong
<kov>
I haven't looked in detail on the reason for the crash but from their talking about bmalloc I'm wondering if it's related to some kind of alignment requirements
<sven>
err… wait, the macOS side is connected to MagSafe?
<povik>
but it's magsafe, i don't expect that to be able to carry thunderbolt
<povik>
yup
<sven>
weird
<sven>
you can try to enable the tps trace points
<sven>
but I kinda expect that you’ll just see a lot of “plug status changed” events
<povik>
that's some file in /sys? or kernel recompile?
<sven>
I’ve always enabled them with bootargs because I usually don’t have any userland but I believe it’s also possible to enable them in sys
<Glanzmann>
tpw_rules: Forgot to use the new device tree?
<tpw_rules>
maybe i need to try jannau's u-boot
<Glanzmann>
Maybe.
<Glanzmann>
tpw_rules: So I did replug my keyboard between usb-a and usb-c and typped a few characters to verify that it works.
<Glanzmann>
tpw_rules: This is with what is currently in bootstrap.sh I rebuild it with the latest sound and kernel warning patch. Also u-boot is coming from that (with the device tree from the kernel).
<tpw_rules>
allegedly u-boot is using the same device trees as the kernel but maybe that is not the case
<Glanzmann>
povik: Sound also works on the mini through the speakers. Now my daughter asks for her song ...
<kov>
tpw_rules, I'm doing some more reading on libpas (the bmalloc replacement, impressive how much work went in since I was active =P) and it seems to use 16k as the smaller page size it cares about, I guess it's no surprise Apple has basically started using 16k as *the* page size ;P
<povik>
yeah, i don't know enough about ftrace to do something useful with it
<povik>
some other day...
<povik>
Glanzmann: well i hope you are putting the drivers to use then!
<Glanzmann>
Of course, small dance session here.
<tpw_rules>
this whole m1n1 and u-boot owning the device tree still really bothers me
<Glanzmann>
hrhr. Wait for m1n1 chainload support.
<j`ey>
think of the dtb like part of the firmware then :P
willemml has joined #asahi
<tpw_rules>
it's not firm enough yet though
<tpw_rules>
hm, now my config boots okay but i get this strange "unexpected GFP" kernel warning: http://ix.io/3Q5e
<j`ey>
its on top of -next.. so possibly some new issue there
<tpw_rules>
also poweroff does not quite work, it hangs for like 5 seconds then resets
<j`ey>
do you have all the SPMI/NVMEM configs?
<Glanzmann>
tpw_rules: poweroff works for me
<tpw_rules>
i didn't change my config at all, i thought it wouldn't be necessary because all the new stuff is default ARCH_APPLE
<j`ey>
not SPMI_APPLE
<tpw_rules>
oh, i missed that one
<j`ey>
marcan: ^
<Glanzmann>
everyone does the question is only how long you search for it. I searched long ...
<tpw_rules>
grr, something is unstable. i keep having random hangs and reboots. i assume there is a watchdog cause i don't see a kernel panic
<Glanzmann>
tpw_rules: Okay, I have no issues on the air other from sound and that is fixed.
<Glanzmann>
tpw_rules: Feel free to try my build artefacts.
<Glanzmann>
And see if the problem persists.
<Glanzmann>
tpw_rules: I'm streesing the mini by building Debian ...
<tpw_rules>
so far it's only happened during boot
<tpw_rules>
i wonder if it's related to that iso driver that's giving that gfp warning
willemml has quit [Quit: willemml]
sri has joined #asahi
<tpw_rules>
so m1.tgz is your rootfs?
<tpw_rules>
also worth noting my stub is still 12.0.1
<jannau>
I see occasionally rcu stalls or hangs during boot, testing with dcp so that could be the cause here
<tpw_rules>
would that print something?
<tpw_rules>
i just see a normal boot sequence, except it stops at some random point and 10 seconds later the machine resets
<jannau>
I don't think 12.0.1 iboot would be a problem
<jannau>
the rcu stalls print something after a while (more than 10 seconds)
<kettenis>
so with the new u-boot you have to have the kernel driver for the WDT
<Glanzmann>
tpw_rules: yes
<tpw_rules>
i have that
<Glanzmann>
sven: After upgrading the kernel, the mini does no longer detect the m1n1 proxy on the air, any ideas?
<jannau>
which usb port do you use on the mqc mini? type-a or type-c? is usb hotplug on the usb-c connectors working?
<tpw_rules>
marcan: can you give some thought to m1n1 issue 159? that fixes a big problem for me
<tpw_rules>
and yeah i just checked, i think the watchdog is working as designed. unfortunately
<tpw_rules>
i'll turn it off and see if it eventually complains about something
<Glanzmann>
jannau: type-c with a superspeed cable.
<Glanzmann>
jannau: Yes, usb hotplug is working, tested with a usb keyboard.
<Glanzmann>
I'm currently downgrading so that povik can continue.
bps has quit [Ping timeout: 480 seconds]
willemml has joined #asahi
le0n has quit [Quit: see you later, alligator]
willemml has quit []
<Glanzmann>
Downgrading did not solve the issue
le0n has joined #asahi
<Glanzmann>
So the superspeed cable worked before, whole day. Now it does not.
<Glanzmann>
Now I used a usb-c to usb-a cable that came with google tv ...
<Glanzmann>
And that seems to work.
<Glanzmann>
No idea what this is about. The superspeed cable came with an eizo monitor to use it as hdmi-over-usb-c cable and to my knowledge I did not replug or tocuh it.
bps has joined #asahi
boardwalk has joined #asahi
<tpw_rules>
jannau: does the system halt completely when you get these stalls?
<sven>
and the usb curse strikes again!
<tpw_rules>
sven: is this related to what you were investigating? i just got an rcu stall message before the watchdog bit me
<Glanzmann>
sven: Is what I saw a usb curse?
<sven>
is there anything in dmesg with the broken cable?
<jannau>
tpw_rules: yes, it halts completely. The rcu stall is supposed to print a backtrace but doesn't. sometime it halts without rcu stall message
<Glanzmann>
As you can see it worked later when I switched to the usb-a. But it messages which are above are all from usb-c tries. I tried several times by rebooting the air.
<tpw_rules>
jannau: okay, looks like that's not dcp's fault. this is just on linux-asahi
axboe has quit [Quit: leaving]
<sven>
strange
<sven>
it looks as if it doesn’t even recognize the cable
axboe has joined #asahi
<Glanzmann>
Hopefully its the damn cable then. :-)
<jannau>
Glanzmann: does m1n1 print any usb-dwc3 messages when connected via usb-c
<Glanzmann>
The usual messages that it opened two serial ports.
<Glanzmann>
povik: Can I reboot the target, than I'll take a screenshot.
<povik>
one moment
<Glanzmann>
k
<Glanzmann>
i hear somethoing
<Glanzmann>
two times
<jannau>
Glanzmann: not necessary, The messages I'm looking for are just printed to the serial console and not to the screen
<Glanzmann>
yes beep
<jannau>
picture not necessary
<Glanzmann>
i see
<tpw_rules>
Glanzmann: i am missing something about how to get the grub config to stick
<Glanzmann>
tpw_rules: reference quickstart.txt and execute the commands.
<Glanzmann>
tpw_rules: You have efi mounted in /boot/efi ?
<Glanzmann>
Put it in /etc/fstab?
<Glanzmann>
Than run the grub commands from quickstart.txt and reboot that's it.
<tpw_rules>
yes, all the commands seemed to execute successfully but grub didn't come up with a menu
<tpw_rules>
do i need to tell dpkg-reconfigure anything or just accept all the defaults?
<Glanzmann>
Okay, can you paste me the output of 'lsblk; mount; find /boot'
<Glanzmann>
tpw_rules: Removeable media path yes; update nvram no
<axboe>
tpw_rules: did allmodconfig and matches your results - 20.8m for 16k ps, 25.9m for 4k ps
atka has quit [Quit: WeeChat 3.4]
<tpw_rules>
axboe: on an m1 pro? that's a bit sad, i had hoped it would be faster
<Glanzmann>
mps: Thank you for your /sys/module/hid_apple/parameters/ reminder. Now everything works for me (caps lock is control; german umlauts and meta alt swap)
<axboe>
tpw_rules: yep, small one though, 6 p cores
<axboe>
tpw_rules: I ran on a 5950x and 12900k for comparison, and x1 is completing it too (but that'll take a while)
<axboe>
tpw_rules: 12900k does it in 12.45 min
<axboe>
I'd say 20.8m is very respectable
<axboe>
not this is allmodconfig x86, so it's basically all of it
<tpw_rules>
ok you probably compiled more than me then
<axboe>
my qemu kernel takes ~85s, and the one I run on the m1 takes ~3 min
<axboe>
I'd say it's pretty damn fast
<tpw_rules>
and the 12900k has what, a 10x higher tdp?
<axboe>
base tdp 125W, turbo 241W
<Glanzmann>
axboe: That are my 5950x numbers: linux 5.10 allmodconfig: Kernel: make -j 64 V=0 &> /dev/null 12184.35s user 1387.42s system 3075% cpu 7:21.31 total
<axboe>
Glanzmann: 541.5 secs here
<axboe>
this is my for-next branch, fwiw
<axboe>
and -j32
<Glanzmann>
I see.
<axboe>
Glanzmann: these are test boxes, and I use them for peak runs hence disable mitigations, prune config etc
<axboe>
what they run, I mean
<Glanzmann>
axboe: Me, too.
<Glanzmann>
axboe: Do you compile in ram or on nvme?
<axboe>
Glanzmann: hmm, is your ram clock right? sad to say I ran mine for quite a while before figuring out the bios set the ram speed way too low
<axboe>
Glanzmann: nvme
___nick___ has quit [Ping timeout: 480 seconds]
<Glanzmann>
axboe: I see. ram clock is right. I use the following configuration. RAM speed is maximum that I can get with 128 GB ram and that board:
<tpw_rules>
that's really what gets me: compiling a kernel on the mini is silent
<Glanzmann>
tpw_rules: On the air is well, but sometimes it gets hot.
<tpw_rules>
well the air doesn't even have a fan does it?
<tpw_rules>
meanwhile my 6 core xeon thinkpad which is like 30% slower still is sitting here screaming and melting stuff on my desk
<tpw_rules>
i lost a chocolate bar to it the other day...
<Glanzmann>
No, it doesn't. Unless povik is doing sound tests that do not wake up the rest of the family int he same room.
<axboe>
my experience on my m1 laptop is that a "normal" compile (which is ~3 min) doesn't spin the fan at all
<j`ey>
the quicker it is, the less time for the fan to kick in :D
<axboe>
the allmodconfig does turn it in after 5 min or so, but it's still way less fan than on an x1 or (god forbid, I had one of these before) a p1
<tpw_rules>
do the fans actually turn off on it? they never turned off on my older intel one
<jannau>
tpw_rules: I'm using gcc "Gentoo 10.3.0 p1", cross-compiled on x86_64
<Glanzmann>
tpw_rules: On the mini the fan is always on but you don't hear it.
<kov>
tpw_rules, Glanzmann one thing I noticed on my testing is that the M1 chips seem to prefer C++/Rust compilation to C
<tpw_rules>
those compilers probably have higher memory bandwidth requirements
<kov>
erm axboe ^
<kov>
tpw_rules, yeah, I figure C++ and Rust need to keep a lot more state while compiling
<kov>
it certainly does use a lot of memory (and binaries are bigger usually)
<kov>
I tend to use building the rust compiler as my benchmark and the difference between the M1/M1 Max and my intel machines is massive
<axboe>
kov: that just makes it even nuttier...
<axboe>
kov: I should try that :)
<kov>
axboe, that'd be great! I'd really like to see 5950x and 12th gen numbers if you have the time
<Glanzmann>
axboe: OUt of curiosity, could you run this on your m1? taskset -c 0 sysbench --memory-oper=read --memory-block-size=128M --memory-total-size=128G --threads=1 memory run
<axboe>
partial to doing kernel compiles as a) that's what I do, and b) no real external requirements for cross compiling
<axboe>
Glanzmann: on the E core?
<kov>
the thing that got me hooked originally was the compile times they were advertising for WebKit (I used to work on WebKitGTK)
<Glanzmann>
axboe: Good point, probably on a p-core
<Glanzmann>
Now that you mention it, I also need to run it on a p-core.
<kov>
but it carried on nicely to rust, which is what I'm doing mostly these days
<kov>
the rust compiler is a nice benchmark for me because it's a mix of C++ and Rust
<Glanzmann>
axboe: Thank you, you just doubled my number.
<axboe>
Glanzmann: 2.7906s, 46962.77 MiB/sec
<axboe>
Glanzmann: ;)
<j`ey>
kov: there is the cranelift backend, for pure rust :P
<axboe>
Glanzmann: 6.7088s, 19533.98 MiB/sec <- E core
<axboe>
kov: easy to cross compile?
<Glanzmann>
axboe: For me it is 19910.95 vs 42604.49
<axboe>
kov: guess we can do native, probably close enough
<kov>
j`ey, hah, but then I lose the C++ part (I still have to compile WebKit and Chrome for work - and for the 16k patches ;D)
<kov>
axboe, yeah, I've done a cross-compile to x86-64 once to see if it made a difference, it's close enough
jmr2 has joined #asahi
<Glanzmann>
axboe: I compared that to my 5950x, but did not notice that I was running on an e-core and was a bit disappointed. My ryzen can go around 30 GB/s
<jmr2>
Glanzmann: regarding your USB issue: how old is your version of m1n1? I'm wondering if commit e1a7deb could help you (it's not included in the installer yet). More details in issue 101.
<Glanzmann>
jmr2: I installed the newest m1n1 as of yesterday.
<jmr2>
OK
<kov>
axboe, btw you probably want to do 2 runs, as it downloads a bunch of stuff, so what I did was I ran the build once, deleted build/{bootstrap,aarch64-unknown-linux-gnu}, then timed the second run (making sure no ccache or sccache was on the way of course hehe)
<axboe>
kov: ok, will do a prime run, then a timed one
<jmr2>
Glanzmann: on a different topic, I'd suggest to add the following CONFIG_ to the wiki: GPIO_MACSMC CHARGER_MACSMC APPLE_PLATFORMS APPLE_SMC APPLE_SMC_RTKIT
<axboe>
kov: what's the make clean equiv there?
<Glanzmann>
jmr2: Do you want to do it or should I do it?
<axboe>
kov: oh nevermind, you literally wrote that
<tpw_rules>
jannau: if i use CONFIG_PREEMPT instead of CONFIG_PREEMPT_VOLUNTARY, it works properly. i couldn't get it to hang in 15 or so boots, whereas with VOLUNTARY it hung every other boot or so
<jmr2>
I think I'll let you do it - you know which rules you've used to determine what to add and not so far.
<j`ey>
tpw_rules: ouch
<tpw_rules>
not going to investigate why that is the case, i just want it fixed...
<Glanzmann>
jmr2: I add anything that I was once missing. So I'm adding them now.
<jmr2>
OK. Thanks.
<j`ey>
arm64 will support PREEMPT_DYNAMIC in the -next soon, tpw_rules
<j`ey>
not that it really helps you now :P
<tpw_rules>
j`ey: i don't really know the differences
<Glanzmann>
jmr2: Done.
<jmr2>
Thanks
<j`ey>
PREEMPT means all(ish) kernel code is preemptable, preempt_voluntary means the kernel has some explicit preemption points
<j`ey>
(and PREEMPT_DYNAMIC means you can switch between all 3 preemption models at runtime)
<tpw_rules>
voluntary sounds like it is probably better?
<mps>
this is announced few months ago, iirc
<Glanzmann>
tpw_rules: Unless you want to find bugs. :-)
<tpw_rules>
do you think that is an upstream problem?
<j`ey>
tpw_rules: the 'full' preemption is meant to be lower latency for interactiveness
<mps>
voluntary is good for long running task
<tpw_rules>
Glanzmann's kernel does not have voluntary
<mps>
(forced) preemt is good for interactive usage
<axboe>
rougly same ratio as kernel compile for 12900k, m1 does proportionally better on rust c++ compile than the 5950x compared to the kernel C compile
<axboe>
oh 5950x g++ was 9.x, let's redo with 11.x like the others...
<kov>
axboe, nice, thanks! that's the same time my standard m1 does on the mac fwiw
<kov>
and my xps 13 1185G7 did it in 44m if I'm not mistaken pff
<axboe>
ain't nobody got time for that
sri_ has joined #asahi
sri has quit [Read error: No route to host]
<axboe>
kov: 5950x (8:16) 1.96x
<axboe>
kov: using g++11 to be more fair
<axboe>
kov: same conclusion, just a bit closer
<kov>
axboe, looks great, seems like more recent intel are much better than older ones (at least the ones that gobble power)
<kov>
axboe, ok, found my notes here, I got 11:30 on macos and 15:23 on the linux 8-core VM running a standard distro kernel on my m1 max
<jannau>
tpw_rules: confirmed, PREEMPT_VOLUNTARY was selected
<kov>
(I haven't put linux bare metal on the max yet, using the air for my testing for now xD)
<kov>
axboe, btw you said you're running these with E cores disabled?
<kov>
just repeated the build on my m1 mini, 21:50, the fact I got ~16m on macos makes me think there may be some more 'need to enable L3 cache' that haven't been found heh
<kov>
I doubt the single core boost would make such a big dent?
<kov>
(now I want to ask povik for his change to linux to build it on macos and compare xD)
<tpw_rules>
it was almost exactly the same time for me when building in a linux VM using UTM
<kov>
tpw_rules, same time as which one? or do you mean the vm did it in the same time as linux bare metal?
<tpw_rules>
iirc the 4k page size VM did it in almost exactly the same time as 16K bare metal but with no cpufreq driver
<kov>
yeah, now that I think about it, I think my test on a VM on the m1 mini did it in ~20m
<tpw_rules>
i think macos was able to make up the time lost with 4k pages by actually speeding up the P-cores
Gaspare has joined #asahi
<kov>
tpw_rules, hmm or is hvf able to hide the 4k somehow?
<kov>
I guess that would require cooperation from qemu though
willemml has joined #asahi
willemml has quit []
<axboe>
kov: E cores disabled on the 12900k, all cores enabled on the m1