You might well have a "memory leak" problem in some of those processes, and this would be indicated if the memory consumption of some process continued to enlarge while the nature of the work that they are doing is such that this sort of behavior would not be expected.

Since it can be difficult to track down these problems in production code, some systems are simply designed so that the processes "commit hari kiri" after a little while. They voluntarily terminate, and are immediately replaced. (Others take a similar approach: they exec themselves.)

Remember, also, that Linux does try to put "100% of available memory" to some good use. A common, lowest-priority use is "file buffers." Linux is completely lazy about cleaning-up such things, because there is no harm and possible benefit in letting them stay around as long as possible.

The situation won't change until, and unless, there is actual memory "pressure." Then, according to a well-established system of priorities, Linux begins taking-back memory ... up-to and including the dreaded "OOM Killer" (which starts shooting passengers and throwing them over the side to save the balloon).

That's entirely consistent and normal. You've got 3.8G allocated to processes (most of it to the chromium-browser) plus another (120M + 2.6G) buffer and cache space that is available for processes if they need it.

Think of the cache space as the kernel saying, "This memory is available, but if some process happens to want the data that's in that cache, I know what it is and where it is and won't have to read it from the disk."