Greetings, we have an app that writes 4k blocks to an SSD partition with more or less random seeks. (For the curious: it's called "update engine" and it's used to install a new Chrome OS version in the background.) The total size of the writes can be a few hundred megabytes. During this time, we see that other apps, such as the browser, block for seconds, or tens of seconds. I have reproduced this behavior with a small program that writes 2GB worth of 4k blocks randomly to the SSD partition. I can get apps to block for over 2 minutes, at which point our hang detector triggers and panics the kernel. CPU: Intel Haswell i7 RAM: 4GB SSD: 16GB SanDisk kernel: 3.8 >From /proc/meminfo I see that the "Buffers:" entry easily gets over 1GB. The problem goes away completely, as expected, if I use O_SYNC when doing the random writes, but then the average size of the I/O requests goes down a lot, also as expected. First of all, it seems that there may be some kind of resource management bug. Maybe it has been fixed in later kernels? But, if not, is there any way of encouraging some in-between behavior? That is, limit the allocation of I/O buffers to a smaller amount, which still give the system a chance to do some coalescing, but perhaps avoid the extreme badness that we are seeing? Thank you for any insight! -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>