this post was submitted on 30 Nov 2023
335 points (98.8% liked)

Technology

59317 readers
4652 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] DreadPotato@sopuli.xyz 39 points 11 months ago (4 children)

According to Phoronix, Ampere's new CPUs have so many cores that Linux doesn't support systems when two of Ampere's 192-core chips (384 total cores) are installed in a single server. For now, the ARM64 Linux kernel only supports systems with 256 cores or less. To fix the issue, Ampere has submitted a patch proposing that the Linux kernel core limit be raised to 512

If you're already at 384 cores in a dual-processor setup, isn't raising the limit to 512 too little? Why not just go for 1024 now that they're at it, especially since the method they proposed doesn't increase kernel image memory footprint.

[–] IHeartBadCode@kbin.social 22 points 11 months ago

Well looking at the patch

+config NR_CPUS_RANGE_END
+	int
+	default 8192 if  SMP && CPUMASK_OFFSTACK
+	default  512 if  SMP && !CPUMASK_OFFSTACK
+	default    1 if !SMP
+

It looks like it's doing and end range of 8192 but with the off stack flag set. And it seems that…

+	  This is purely to save memory: each supported CPU adds about 8KB
+	  to the kernel image.

Which looks like they're trying to save memory to avoid TLB stalling on the CPU's bitmap. I think if the chip maker is indicating that slab allocation is fine for more at the moment (which the patch looks to be coming from Christoph Lameter, who works at Ampere), it's best to assume they've tested it on their end. Or at least I would think so. If they felt that more on the stack was a fine option, I would think that, that's exactly what they would pitch to the KML. Them saying there's a need for offstack past 512, I'm guessing there's a reason and the one I can think of is TLB stalls.

[–] gravitas_deficiency@sh.itjust.works 5 points 11 months ago* (last edited 11 months ago)

I dunno, man. 512 cores ought to be enough for anybody.

Edit: guys come on I shouldn’t have to explain the joke

[–] LennethAegis@kbin.social 4 points 11 months ago (1 children)

I agree, they are just going to hit the wall again way too fast. If the limit is 256 or 2^8, they should increase it to 65536 or 2^16. Now that's a limit that feels safer to leave at for many year to come.

[–] BigDanishGuy@sh.itjust.works 9 points 11 months ago (1 children)

Or do what ietf did "We're running out of 32bit addresses, should we add some bits and call it an even 48? No! Let's double the number of addresses 96 fucking times!"

Start using 128bit for everything.

[–] gravitas_deficiency@sh.itjust.works 4 points 11 months ago* (last edited 11 months ago) (1 children)

If you have to solve a problem, do it in a way that solves it for good.

Max value of uint128 is ~340 undecillion (~3.4e38).

[–] jsh@sh.itjust.works 3 points 11 months ago (1 children)

Is it fair to assume that those are more cores than there ever has and will be made?

Honestly, I think so.

[–] just_another_person@lemmy.world 4 points 11 months ago

Fine point. I assume because they know there is an entire waterfall of shit they don't want to mess with regarding memory registers for SMP, and they know this is the limit where they can patch and not have to deal with all of that.