Linux Filesystem, Storage, and Memory Management Summit, Day 1

Quite a comprehensive summary of the session. Speaking of the session, are there any videos of these recorded ? Also, during these summit, is there any irc channel used to discuss the current agenda ? That would be cool.

Coming to the topic,

1. I remember a discussion about the equivalence between network and block devices and what one can learn from another. So, can't these writeback issues be handled like how congestion is handled on a network with a window and such, along with something like retransmission in case of overloaded scheduler, albeit with tweaks taking into account reliability and speed. Having a single window for writebacks as mentioned in the article will help in this case.

2. Speaking of the alternative patch mentioned, yes, the formula for bandwidth calculation is/was indeed mind-boggling though it may be the right one. Making the 'dirtier' sleep for some time seems right to me. This is not going to impact the latency from my POV, should affect only the throughput since perpetual dirtiers are often batch jobs like rsyncs etc.

3. """
Hugh Dickins voiced a concern that frontswap is likely to be filled relatively early in a system's lifetime, and what will end up there is application initialization code which is unlikely to ever be needed again
""
Good point. All the 'cold' and/or 'init' sections may well end up in cleancache. There will need to be a way to discard these and keep the 'victim' pages evicted. Speaking of KVM in that context, can't KVM KSM and/or ballooning code make use of this ? I am sure KSM may benefit hugely from this.

4. Concept of memory controller groups sounds nice but last time I checked them there was a caution attached about a sizeable overhead associated with them, so unless I am dealing with large quantities of memory to overcome the overhead, are they going to be of use ? Also, good to see some real world applications of these.

"He would like to see more graceful behavior when memory runs out in a specific control group; it should be signaled as a failure in a fork() or malloc() call rather than a segmentation fault signal at page fault time."

I think this was an article few weeks back about behaviour of OOM killer inside a cgroup and how to handle it.

"His main wishlist item was the ability to limit memory use based on the device which is providing backing store"
Quite interesting.

5. Filesystem overhead -- Yes, I have seen this discussion more than once - about precisely what a filesystem is doing, I use atop with disk accounting patches to get per-process statistics about disk utilization, but as pointed out a fine grain view into metadata etc is better. Recently I had issue with deletion of recent reflinks created on a btfs filesystem resulting in a CPU storm. I was not able to get a deeper view beyond the usual one.

Lastly, I was wondering whether there is any proposal to extend the existing autogroup facility to cgroups of other kind -- blkio and/or memcg. It would be interesting to see the results of this.