blitzkrieg3

On the 37th floor of my office buildin I didn't even feel it. Others said they thought it was the wind. Tuned mass dampers are no joke.

And he references the exact blog post here. I hear it as 6/8 (definitely a rest after the first three 16th notes which is born out in the timing) and I still think that's closer, but I appreciate the 21/32 argument and glad to see him actually try to find a common subdivision to those timings

If I had to guess it's because this one is unbranded and released as open source

mmap() will keep things in memory after first loading, but the page cache will _also_ keep things in memory after first loading. The difference is in order to re-use that you still need to read the file and store yourself (requiring 2x memory), instead of just doing a memory access. This has two consequences:

* 2x memory. A 20G data set requires 40G (20 for page cache and 20 for LLaMA)

* Things would be _even slower_ if they weren't in page cache after first loading. mmap is fast because it does not require a copy and reduces the working set size

This is a misconception you and parent are perpetuating. fork() existed in this problematic 2x memory implementation _way_ before overcommit, and overcommit was non-existent or disabled on Unix (which has fork()) before Linux made it the default. Today with CoW we don't even have this "reserve memory for forked process" problem, so overcommit does nothing for us with regard to fork()/exec() (to say nothing of the vfork()/clone() point others have brought up). But if you want you can still disable overcommit on linux and observe that your apps can still create new processes.

What overcommit enables is more efficient use of memory for applications that request more memory than they use (which is most of them) and more efficient use of page cache. It also pretty much guarantees an app gets memory when it asks for it, at the cost of getting oom-killed later if the system as a whole runs out.

It does not happen using fork()/exec() as described above. For it to happen we would need to fork() and continue using old variables and data buffers in the child that we used in the parent, which is a valid but rarely used pattern.

It's also a 20 year old read.

Edit: Many of these proposals in that have either been followed or exceeded, largely as a result of the September 11th attacks. Most notably Broad street is completely a pedestrian plaza, closed off to traffic.

> I've worked at RHT and based on the turnaround, it's the guy that writes codes for the card reader. I'm still impressed but not surprised by the level of service he got. Red Hat has a great hacker culture.