I'm running Debian stable with kernel 6.5 on an ARM M1 MacBook Air. The biggest issue is that RAM and VRAM are unified, and there is no particular way to even check how much of the used RAM is VRAM (as confirmed by the main Asahi Linux developer).

This causes the system to constantly hang when it is approaching less than 500 MiB free RAM. Theoretically, I can allocate memory using the stress program, and the kernel will kill it, but in practice any other program that's using too much memory ends up hanging the computer because the kernel does not account for the VRAM portion of the memory used. The kernel will kill programs using 200 MiB of RAM but leave ones using 3 GiB VRAM alone.

Creating a SWAP doesn't help either, because the moment the kernel starts swapping at all, the system hangs instantly without even time to write logs.

Is there a sysctl or a kernel parameter I can set to disable disk cache to RAM to keep more RAM free? I have to constantly run a drop-caches script to keep the system alive, I have it bound to a keyboard shortcut, and automatically run after some programs close.

The crashes sometimes happen with the most basic use (4 YouTube tabs open in Firefox and someone calls me on Telegram, or sends me a 60 second video which Telegram automatically downloads).

Any answer to such question I find is along the lines is "you're stupid, you don't need to disable caching, don't ever ask that again", no actual solution.

There's gotta be a better way than putting something like "while true; echo 3 > /proc/sys/vm/drop_caches ; sleep 60" & into /etc/rc.local

I know this is not the right fix to the issue, but I need to stop the kernel from caching to have as much free RAM as possible.

  • If what you write is true, everyone would have the same problem. Neither Debian stable nor the M1 MacBook Air are very unusual systems, so you'd expect more reports. Do you have anything that shows the actual behaviour? Logs when it happens etc?
    – pipe
    Feb 14 at 18:59
  • @pipe like i said, system doesnt have time to write a log when it freezes. Sometimes just before, the kernel will complain that kswapd hangs. If you look at any Asahi linux forums, such as on the subreddit, that is the absolute #1 issue with it (everything else is compatibility with certain USB devices, audio, HDMI, basic stuff) Feb 14 at 19:10
  • ive daily driven systems with unified memory before (Intel, ARM Pinebook pro), didnt have issues like this, but those video drivers are a lot more stable than the ones for M1 graphics the Pinebook had unified memory and only 4G in total, so it's not even a fair comparison. The macbook has 8G Feb 14 at 19:13
  • Have you tried the kernel boot parameters mem and/or memmap to limit and define the amount of available physical memory? Feb 14 at 22:17
  • @ChrisDavies is this for completely limiting how much physical ram the kernel will have access to? or for limiting regular RAM use and leave some as VRAM? Afaik, the kernel considers both as one, and it'll just limit the total making it worse Feb 15 at 17:25

2 Answers 2


I'm highly dubious about the provided rationale for what's going on.

AFAIK, modern Macbooks do not have special separate RAM regions for RAM and VRAM, it's a single unified chunk of memory which can be used by applications both for RAM and VRAM allocations, and it's the Linux kernel that should make sure RAM allocations don't eat into VRAM.

What you're describing sounds like a kernel bug that you should report to Asahi developers.

You could try using the mem=MAX_RAM, e.g. mem=7G (7 gigabytes) kernel boot option and see if it helps but I doubt it will.


Like Artem I am very dubious about this. I am not specifically familiar with the MAC M1 architecture but have run Linux on lost of systems where the video uses main RAM - IME this has always been statically allocated long before any user processes start.

But assuming that your assertions are valid, I would try to solve the problem by a strict 0% overcommit on memory:


(I suspect that both overcommit_ratio and overcommit_kbytes will not accept negative numbers - but this is definitely worth testing if the values above do not resolve).

UPDATE Subsequent comments suggest this just the usual overcommit/OOMKiller issue. If this is the case then the suggestion I made here is the right way to fix the problem, although an overmmit ratio of 0 is perhaps over-zealous. Check your logs.

  • i understand, I've run Intel systems with their built-in HD graphics, and a much weaker pinebook pro with 4G unified memory (and now even pinephone pro same SoC) but the problem only appears with heavy ram use, sometimes this can be having a large PDF open, sometimes a shitty site like youtube which could use like 1.5G just for the 1 tab It's gotten to the point where I'm constantly monitoring and mindful of everything that's running, which is not something I had to do with past computers tbh Feb 15 at 17:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .