>UNIX-like kernels are easy, in that you don't have to have >that much running before you can run "Hello World".

Well, it depends on what you mean by "Hello World". Simply printing it out from the kernel? Easy. Getting a workable userspace up and running so a user program prints out "Hello World"? Hard. Also, you can have a microkernel that gives you a UNIX-like personality too (as is it is often the case when implemented), so I am not sure how one precludes the other.

>Also, the emphasis on virtual memory and page faults is >becoming dated. Paging out to disk is obsolete technology. >RAM is too cheap, and mobile devices don't page.

Uh, of course mobile devices use paging and virtual memory. You might be conflating virtual memory with swapping here.

Non CS-major here (in fact I did math). I don't know anything about kernels or micro-kernels. Easy cases, even grossly over-simplified cases would be relevant.

I know that every time I run a command into bash Linux is doing all sorts of fancy memory-allocation and queueing and more. All the books I am finding are either way too technical or grossly out of date.

Here is a cute course on Compilers: http://web.stanford.edu/class/cs143/

Actually they are not that out of date... Tanenbaum's Operating Systems and Computer Networks are both good. The BSD book by McKusick is excellent for more advanced students. For example, they don't cover SMP much, but locking and queuing, so you are prepared for studying SMP.

> Also, the emphasis on virtual memory and page faults is becoming dated. Paging out to disk is obsolete technology. RAM is too cheap, and mobile devices don't page.

I've got to admit, I thought of John Carmack advocating for pretty much the opposite direction for operating systems earlier this year, for making greater use of memory mapped files, unified virtual memory for CPU and GPU, and so on: https://twitter.com/ID_AA_Carmack/status/742191010013286400

I wonder what you meant by "mobile devices don't page."

> I wonder what you meant by "mobile devices don't page."

Mobile devices have memory-mapped pages, but they don't have VM or overcommit. Your process just gets killed if it's using too much memory.

Page faults are still important though… actually even more important.

Are we talking about the same thing when we say "mobile devices?" Like, Android phones? Because if there's something lobotomized about their virtual memory, that's something I'm curious about, if you could share a reference of some sort.

I don't know if Android swaps (almost certainly not) but iOS does not swap. It doesn't have a pager. Of course it does have "VM".

I dug into it a little. It's mostly for posterity at this point but if anyone wants to read about it, look up the Android lowmemory killer, which is sort of an enhancement to the OOM killer's functionality. It's a conventional enough Linux virtual memory otherwise.

He's a game developer, and struggles with the communications problems between the application and GPU. Remember that in Carmack's worldview, the game owns the entire display. It's not one window of many.

Let me quote Carmack on the issue of mmapped assets so other people can see whether you're truly presenting his world view or something you just made up.

On startup, applications would read-only mmap their entire asset file [..]

Splash screens and loading bars vanish. Everything is just THERE.

You could switch through a dozen rich media application with a gig of resources each, and come back to the first one without finding that it had been terminated to clear space for the others [..]

It will save power. Hopefully these are the magic words. Lots of data gets loaded and never used, and many applications get terminated unnecessarily to clear up GPU memory, forcing them to be reloaded from scratch.

There are some well founded reasons to be skeptical about this at first glance, until you realize that we are moving toward a world where hardware supports having CPUs and GPUs in the same address space (and the support is there on some mobile devices and HSA-supporting desktops). Expanding support for these traditional VM techniques to use the hardware to its fullest only makes sense.

Mobile devices don't page because killing a process on a device which is usually only showing the user one thing at a time, due to want of memory, isn't usually that big of a deal.

iOS does have VM though, and apps use it to implement home brew memory paging. Obviously not useful for the stack, so it encourages more explicit memory management. The mmaped region is bizarrely counted towards the total, leading to windowed memory schemes from the 1960s, where mmaps are remapped to access different chunks of data. Some poor design choices.

Also, app code is paged in, it just doesn't need to be paged out.