Linux

48185 readers

1199 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
No misinformation
No NSFW content
No hate speech, bigotry, etc

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago

MODERATORS

[email protected]

117

[ARCH] [EASYAF] Use RAM for Firefox and boost performance and decrease drive wear (wiki.archlinux.org)

submitted 8 months ago by [email protected] to c/[email protected]

29 comments fedilink hide all child comments

Might be late to the party, but I just discovered you can do this. Super simple and easy to do.

After having a read of the linked page, I backed up and just used this option:

https://wiki.archlinux.org/title/Profile-sync-daemon

Installed, created config, and enabled service:

systemctl --user enable psd.service systemctl --user enable psd-resync.service

I definitely notice an increase in speed and less SSD usage should hopefully increase lifespan.

I'm sure there would be options for alternative distros, anything using Systemd should be able to use the daemon.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 17 points 8 months ago (2 children)

Finally, a way to use the loads of RAM I have other than Compiling and Blendering.
Well, I guess we also have RAM drives

[–] [email protected] 1 points 8 months ago

Mount .cache as tmpfs. Rarely needs a workaround for some offenders to XDG spec though.

[–] [email protected] 10 points 8 months ago (1 children)

Just reconfigured /etc/makepkg.conf to use extra cores and tmpfs.. I've been compiling on the SSD with one core for so long it's embarrassing.

[–] [email protected] 3 points 8 months ago* (last edited 8 months ago) (1 children)

While you're still in your makepkg.conf, don't forget to set march=native (and remove mtune) in your CFLAGS! (unless you're sharing your compiled packages with other systems)

[–] [email protected] 2 points 8 months ago (1 children)

Where's the difference between march=native and march=x86-64 in that case?

[–] [email protected] 5 points 8 months ago* (last edited 8 months ago) (3 children)

A ton of difference! march stands for microarchitecture levels (or feature levels). "x86-64" is the baseline feature set targeting common x86_64 instructions found in early 64-bit CPUs, circa 2003. Since 2003 obviously there have been several advancements in CPUs and the x86_64 arch, and these have been further classified as:

x86-64-v2 (2008; includes the SSE3, SSE4 instructions and more)
x86-64-v3 (2013; includes AVX, AVX2 and more)
x86-64-v4 (2017; includes AVX512 mainly)

So if you're still on x86-64, you're missing out on some decent performance gains by not making use of all the newer instructions/optimisations made in the past two decades(!).

If you're on a recent CPU (2017+), ideally you'd want to be on at least x86-64-v3 (v4 has seemingly negligible gains, at least on Intel). There's also CPU-family specific marches such as znver4 for AMD Zen 4 CPUs, which would be an even better choice than x86-64-v4.

But the best march you want use is of course native - this makes available all instructions and compiler optimisations that's specific to your particular CPU, for the best performance you can possibly get. The disadvantage of native is that any binaries compiled with this can run only on your CPU (or a very similar one) - but that's only an issue for those who need to distribute binaries (like software developers), or if you're sharing your pkg cache with other machines.

Since the flags defined in makepkg.conf only affect AUR/manual source builds (and not the default core/extra packages), I'd recommend also reinstalling all your main packages from either the ALHP or CachyOS repos, in order to completely switch over to x86-64-v3 / v4.