| amarsh04 | a large number of packages rebuilt with amd64 PAC/BTI support just hit Unstable/Ceres | 02:13 |
|---|---|---|
| rwp | Not to be too much of a pedantic but I think you mean s/amd64/arm64/ there with the PAC/BTI support support. AFAIK it's an ARM thing. | 04:37 |
| amarsh04 | rwp, I think that it is both amd64 and arm64https://lists.debian.org/debian-devel/2022/10/msg00314.html | 05:08 |
| amarsh04 | https://lists.debian.org/debian-devel/2022/10/msg00314.html | 05:08 |
| onefang | rwp I have yet to see any browser using half my RAM. Having 256 GB helps. B-) | 05:12 |
| thecdnhermit | onefang: i dream of the day i can have that much ram...i don't even have close to that in my server lol | 06:22 |
| joerg | onefang: on a system with 16GB RAM I frequently seen FF eating a 11GB out of that, or more, using swap. What I never seen is linux kernel using a 50% RAM for filesystem buffers and not freeing them as needed | 09:41 |
| joerg | actually I think the fs drivers will use as much RAM as they can get and use, for buffers, up to a maybe 90% or 100%. But they'll free any such buffers as soon as some process demands RAM | 09:43 |
| djph | indeed | 09:53 |
| rwp | amarsh04, Wow! Thanks for that. I had totally missed that it is a feature also available in newer amd64 now too. I had so far only seen arm discussions. | 17:01 |
| rwp | It does seem generally like a good thing to do in the system. Because vulnerabilities do tend to use those techniques in exploits. If hardware support can layer a block to it at compile time then that seems reasonable to me to layer in there. | 17:02 |
| rwp | onefang, Go ahead and gloat about your massive RAM! :-) My desktop'y machines are all 16GB in size. | 17:04 |
| Alverstone | 16 GB is a good amount | 17:05 |
| amarsh04 | going from 8GiB to 16GiB made a big difference to me, mainly being able to avoid excessive swapping | 17:06 |
| rwp | joerg, Agreed. The Linux kernel uses RAM for file buffer cache rather well and efficiently. It does a good job. I do have systems where use a lot of buffer cache such as file server systems, because, file server! It's what it does and so naturally most of it is in file system buffer cache, which is perfect for a file server. | 17:06 |
| Alverstone | 8GB is too little | 17:06 |
| Alverstone | especially with heavy software suites | 17:07 |
| Alverstone | and when you have to run windows in virtual machines | 17:07 |
| Alverstone | for example win 7 runs well on 3GiB of RAM most of the time, but win 10 requires at least 5-6 to do anything useful | 17:07 |
| rwp | For a desktop 8GB is less than best today running web browsers. I still have a few machines at 4GB and 8GB but have to be careful how I use them. Definitely NOT running MS-Windows VMs there! | 17:08 |
| n4dir | 8 Gigs work fine here | 17:08 |
| rwp | Running a VM is running a whole other system in addition to your current system. Meaning that you really need enough RAM for both. More ran there is always good. | 17:08 |
| Alverstone | rwp the main bottleneck is GPU though | 17:09 |
| rwp | I am actually typing this on my 8GB x220 laptop. It's working well. But I am not running Microsoft VMs on it or compiling the kernel in the background or anything. | 17:10 |
| rwp | I am also not playing FPS games on these systems either. | 17:10 |
| rwp | For me personally the GPU is not the bottleneck. | 17:10 |
| Alverstone | compiling kernel isn't a big deal, it's not updated very often so spending a few hours on it isn't a problem | 17:11 |
| Alverstone | I do 'nice -n 20' and 'ionice -c 3' on it and forget about it | 17:11 |
| rwp | I totally understand that other people want fast GPU graphics for gaming and that's fine, though can be a challenge to achieve through a VM system. | 17:11 |
| Alverstone | though fs cache overtaking RAM irks me a bit, because other software I run uses disk more often as the result | 17:11 |
| golinux | I'm with you nadir . . . 8 gigs does it for my simple needs . . . | 17:11 |
| CueXXIII | 'schedtool -D' also helps for compiling jobs not slowing the desktop down | 17:12 |
| golinux | But . . . this is not a support discussion . . . or maybe I missed something . ;) | 17:12 |
| golinux | OT? | 17:12 |
| Alverstone | cpu cgroup can set ultra low priority for compiler, so low it won't get in the way at all, I don't remember how though | 17:13 |
| Alverstone | golinux, dunno why this isn't in offtopic tbh :) | 17:13 |
| amarsh04 | yes, ionice -c3 for kernel builds | 17:14 |
| rwp | There should never be any complaints about Linux kernel file system buffer cache use as it is putting unused RAM to work speeding up file access. Any userland which asks the system for more RAM will get it and the system will reduce file system buffer cache to give it to those processes. | 17:17 |
| rwp | I think what people are misinterpreting is that when there isn't any memory for file system buffer cache then the system is going to run VERY SLOWLY due to lack of buffer cache due to running at storage speeds at best. SATA is only 6Gb/s and that's slow by today's standards. | 17:18 |
| rwp | The problem is *never* that the system is using RAM for file system buffer cache. But the problem is *often* that the system is short of RAM to use for both userland processes and buffer cache. | 17:19 |
| Alverstone | I agree that linux does a good job of managing RAM, at least when you have enough of it | 17:21 |
| Alverstone | I've heard there are bizzare bugs when RAM runs out | 17:23 |
| Alverstone | I've experienced some unholy lagging myself | 17:23 |
| n4dir | on this 8 Gig machines usually 6 Gigs are idling. | 17:24 |
| Alverstone | I once overdid my image editing and ended up filling all RAM and SWAP and you bet I just plugged off the power | 17:24 |
| Alverstone | even sysrq went unresponsive | 17:24 |
| rwp | The other typical problem with low RAM systems is *lack* of swap causing the Linux kernel to trigger the Out Of Memory Killer. OOM death of random processes getting "kill -9" to death and then those are not running when one is expecting them to be running. | 17:33 |
| rwp | I once had my entire X Window process killed by the OOM Killer and it was rather disturbing as I had unsaved work in another window. | 17:33 |
| Alverstone | OOM is a common battlefield against linux iirc | 17:36 |
| Alverstone | easier not to trigger it | 17:37 |
| rwp | I disable it. And enable enough swap so that I can suspend-resume. Which means I never trigger the OOM Killer. (vm.overcommit_memory=2 but if you don't have enough virtual memory it will panic your system, caution) | 17:40 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!