Hacker News Reader

Comment by danielparks | Hacker News Reader

There’s more information, including a copy of the image, in the forum discussion. The forum seems a bit pokey for me at the moment, though.

https://forums.flyingmeat.com/t/memory-consumption-when-open...

Gus Mueller (the author of the linked tweet) is the author of the Acorn image editor.

View on HN

Thanks for the link. The issue seems to be the IOAccelerator framework:

> I’ve narrowed it down quite a bit (and submitted it to Apple as FB9112835).

> What’s going on is that the IOAccelerator framework has some sort of massive leak in it, where it’s using up 35GB of ram, 25 of which is going to swap (which is why you’re seeing kernel_task flake out).

> On intel, the same image only uses 1480K from IOAccelerator.

Wow. This can explain some of excesive swap usage on M1.

And yet it's relatively performant, says a bit about the quality of components in apple hardware (SSD in this case)!

Seems like a poor conclusion to draw with this little information.

People have reported their SSDs filling up (in terms of total writes) much faster on Apple Silicon machines. If IOAccelerator can leak like this then it would definitely explain it. 25GB swap for one image is absurd. Multiply that by a few months of usage. It may not be a smoking gun but it is a fingerprint in the pool of blood.

That’s been debunked.

It hasn't been debunked if there's no source for the claim...

Apple said that the kernel interface used by smartctl is emitting invalid data, which invalidates all conclusions drawn from it, such as “there is/isn’t a problem with SSD wear”.

Can you provide a link please?

I compared smartctl output with activity monitor on disk writes and it's exactly the same number. You can do the same.

https://appleinsider.com/articles/21/02/23/questions-raised-...

> "While we're looking into the reports, know that the SMART data being reported to the third-party utility is incorrect, as it pertains to wear on our SSDs" said an AppleInsider source within Apple corporate not authorized to speak on behalf of the company. The source refused to elaborate any further on the matter when pressed for specifics.

We'll likely never hear anything else about this again from Apple officially or unofficially, so I don't expect anyone who believes there's an SSD wear issue to stop believing that there is. Either the combination of "smartmontools is emulating SMART access, but doesn't actually have it" and "a source at Apple said that smartmontools is incorrect" is enough to make this a non-issue, or it's not — and since most people who think that there is a wear issue don't realize the part about smartmontools faking that it has access to SMART data in this scenario (hint: nope!), I don't expect to find common ground.

So as far as I'm concerned, this is all irrelevant until someone's SSD wears out, and no one's reported that, so everyone is all tempest-in-a-teapot over some numbers that an open source tool is handcrafting from a macOS kernel API based on assumptions about Apple's proprietary hardware that are probably wrong. Wake me up when someone's SSD wears out.

That Apple comment is bullshit. We've confirmed that the TBW numbers from smartctl match the actual quantity of data written. You can also see the excess I/O in Apple's own Activity Monitor. The lifetime usage numbers smartctl reports are in line with what a high-end SSD would report, and there is no way for smartctl to "make up" the data. It's real data coming from the NVMe controller. There's no possible way to fake anything like that. That person is not authorized to speak for the company and is probably making stuff up.

Apple are aware of it, the bug is fixed in 11.4, and once the corresponding XNU source code drops I'll be happy to diff it and show you exactly what they changed in the swapper to fix it and debunk your "debunking".

Excellent! Glad to hear it.

If this were the cause people would have noticed having 0% free memory way before their SSDs started dying.

Perhaps, but if you read the Twitter thread others are suggesting the same thing and people seem excited/happy that there is possibly a potential fix that may come from Gus discovering this.

So, maybe premature to get too hopeful but certainly not too soon to look in that direction?

People are suggesting the same thing because it sounds nice to be able to correlate them, but the evidence just does not exist yet. At the moment is seems somewhat likely that they are correlated at all, really.

Note that IOAccelerator memory usage doesn’t necessarily mean a bug in IOAccelerator. If my memory is correct, when an app allocates buffers for hardware-accelerated graphics, that memory is attributed to IOAccelerator. So it’s still likely to be a bug in some system framework that’s allocating all these buffers (especially since we only see the issue on one platform) — but an application bug is still a possibility.

Reply on news.ycombinator.com