> > So tell me again how the VM can rely on the filesystem not > > blocking at random points.>> I can write a patch to make writepage() in the non-"mmapped > creation" case non-blocking on journal. But I'll also have to find > out whether it really helps something. But it's probably worth > trying...

_all_ the problems i ever had with ext3 were 'collateral damage' type of things: simple writes (sometimes even reads) getting serialized on some large [but reasonable] dirtying activity elsewhere - even if the system was still well within its hard-dirty-limit threshold.

So it sure sounds like an area worth improving, and it's not that hard to reproduce either. Take a system with enough RAM but only a single disk, and do this in a kernel tree:

And try to use the system while this workload is going on. Use Vim to edit files in this kernel tree. Use plain _cat_ - and i hit delays all the time - and it's not the CPU scheduler but all IO related.

I have such an ext3 based system where i can do such tests and where i dont mind crashes and data corruption either, so if you send me experimental patches against latet -git i can try them immediately. The system has 16 CPUs, 12GB of RAM and a single disk.

Btw., i had this test going on that box while i wrote some simple scripts in Vim - and it was a horrible experience. The worst wait was well above one minute - Vim just hung there indefinitely. Not even Ctrl-Z was possible. I captured one such wait, it was hanging right here:

And it's not just sys_fsync(). The script i wrote tests file read latencies. I have created 1000 files with the same size (all copies of kernel/sched.c ;-), and tested their cache-cold plain-cat performance via:

So the problems are all around the place and they are absolutely, trivially reproducible. And this is how a default ext3 based distro and the default upstream kernel will present itself to new Linux users and developers. It's not a pretty experience.

Oh, and while at it - also a job control complaint. I tried to Ctrl-C the above script: