Every time I start the system, this error appears:

Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
Spectre V2 : Spectre mitigation: LFENCE not serializing, switching to generic retpoline
Spectre V2 : Mitigation: Full generic retpoline
Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch

Sorry if the English is bad, I'm using a translator.

Does your system still work/boot?
Unless you're running a server you can probably forget about the error.

Have you searched for the error?

Are you aware of the Spectre security vulnerability?

Yes.

Yes.

Yes.

My processor model is: AMD Athlon(tm) 64 Processor 3500+

In short: I want to know, if it is worth solving this problem. If I solve this problem, my computer's performance will increase.

Spectre is problematic only for servers that run untrusted code.

If a client machine is running any code that is trying to steal your data, there are much easier ways to do that than Spectre.
Ed

Note that this is not saying spectre mitigations are not in place, or that you should disregard security, its simply saying a different means of mitigation is being employed. You can run spectre-meltdown-checker (https://github.com/speed47/spectre-meltdown-checker) to check this - I have an older Athlon64 that throws this same output in dmesg as well, and spectre-meltdown-checker seems to indicate the cause is a lack of microcode support on the CPU's side (this is unfixable on our end - AMD would have to do it), unless I'm fully misunderstanding the output (and to note: my newer AMD systems show a microcode update associated with this mitigation).

As far as 'will your machine perform better' - probably not, because this is 'as good as it gets' for that CPU would be my guess. As far as rolling back to some older, unpatched kernel, I'd probably not do that, and just let this go as-is. The really severe performance impacts that made it into the news were A) largely overblown and B) mostly confined to Intel chips, so basically 'it is what it is.' If you want more performance for this computer, I'd say you're better off upgrading the CPU - Athlon64 3500+ is exceptionally dated, and even if you don't want to/can't build an all new computer, you can probably upgrade to a faster CPU (you'd need to know which socket your 3500+ is - if its a socket 939 or AM2 you can probably get a dual-core; if its an AM2 you may even be able to get a triple, quad, or hexa core).

I suspect the opposite.
Fixing the SPECTRE vulnerablility will definitely and significantly decrease performance.
Which is why, IIRC, the mainline kernel leaves it unfixed; it's up to the user to activate the fix.

It looks like "If I solve this problem, my computer's performance will increase." has been misinterpreted. Excuse me for forgetting the question mark, I was asking a question and not a statement. (Perhaps, the translator is leaving the context a little different)

Then Slackware and Ubuntu aren't using 'the mainline kernel' because on all of my systems it shows as patched against the myriad CVEs and I'm not 'enabling' anything explicitly - again, the notice that this user is getting DOES NOT indicate that protection is not applied, it indicates that protection is 'falling back' due to not finding an MSR that it otherwise expects, and it's on AMD to provide a microcode update to make that MSR available (and they aren't doing that for K8 - I know 15h and Zen are updated, I honestly do not recall if K10 is updated, but they have said K8 and K7 will not receive updates due to age). Also note that the performance woes are really only associated with newer Intel chips (especially Skylake+) on (largely) synthetic benchmarks/workloads, although there is (reportedly) a hit to database performance that may translate to a real-world loss of some % but nothing is going near the 30-40% that the doomsayers originally insisted (which is what, I believe, prompted most people to believe they should 'go without' patches). On AMD and ARM the performance impacts, where even applicable (remember that AMD and ARM are largely unaffected by a lot of the spectre/meltdown CVEs) , is negligible. On Intel, the real-world performance hit is also fairly minimal, but still measurable on platforms where you can test with/without patching - since 9th gen the patches are baked-in from the factory, and this was expanded with 10th and 11th gen, and this does mean that when you see 10900k being compared to Ryzen whatever, there is no 'subtract some % once its secured' - its already doing what it should be doing. The 'worst affected' in terms of performance were the early Skylake chips with SGX that do not have hardware fixes, but even there it is not the 30-40% that made headlines a few years ago.

As I said in my reply, you very likely cannot 'fix' this - the lack of a microcode update is the 'problem', and only AMD can fix that, and they aren't going to do it for a nearly 20 year old CPU. That being said, your system is working as well as can probably be expected given the context, and it is applying protection against one of the two 'big' CVEs out of this that its potentially vulnerable to. If you want more performance, I would figure out what socket that 3500+ is in, and replace it with something faster.