Just a few words about this "slowdown" thing.
I use linux-2.6.11-cko1-swsusp2 with reiser4 included. I won't upgrade to
a new version until Hans says the current one is at least as stable as it
was before starting the merge...
I get the "slowdown" once in a while, usually for 2-5 seconds, it's not
that annoying.
However :
If I understand well, when memory is needed (memory pressure), reiser4
triggers a flush and writes dirty pages to the disk in large quantities.
This has many advantages like not writing at all the temporary files
which already have been deleted, deferred allocation, etc, it's really
cool.
However when "memory pressure" (ie. need to free some RAM) occurs, it is
usually that I am doing something interactively, like opening a document
or starting some software. Or it might mean that the database server just
received a big query which needs some sorting space in RAM for instance.
Thus, "memory pressure" almost always means "I need memory NOW and
someone is waiting in front of their screen for it"...
And it is at this very moment that reiser4 has to flush (to free
memory).
Thus the "flush storm", by nature, always happens when you don't want it
to happen. It almost never happens when you are away from the computer
taking a leak, for instance.
This is analogous to the problem caused to postgres by checkpointing...
the postgres guys implemented a background writer to solve this.
I wonder if reiser4 could do the same, ie. trickle down dirty pages to
free up memory before it is actually needed, to improve reactivity. There
is a balance to be found, of course, between flushing as late as possible
(to benefit from all the nifty reiser4 features) and flushing earlier (to
avoid triggering the "flush storm").
Maybe this could be set via a few controls...
- tell reiser4 to try to keep X amount of RAM immediately available
without flush
- when the CPU is idle, and/or when the disk is idle, start flushing,
but stop doing it as soon as some CPU is needed, or a key is hit...
- just do frequent, small partial flushes which will keep good locality
of reference while being small
- do it at a lower priority so that the keyboard does not stop
responding !!!
Huh, well, that's it... what do you think ?
When fsyncing, Reiser4, to my understanding, isn't allowed to put
stuff in it's memory cache - it must put it to disk right away. And
This is the whole point of fsync, yes.
Now, it's pretty stupid for evlolution to issue a fsync() on every pixel
move or whatever.
fsync() is for databases or things which must survive a hard system
crash...
evolution could as well have used fflush() and everything would have been
alright. Dumb.
For comparative purposes, I hear of consumer systems with 2 or 4 GB of
ram, and I know of brand new PC hard disks which have a throughput of
less than 5 MB/s (my hard disk maxees out at 20 MB/s on my PC.) Do
you know the throughputs of your drives, and the size of the memory in
your machines?
Hum. A crap laptop harddrive will do 15 MBytes/s and a recent normal
desktop drive (7200rpm ATA or SATA) will do 50 MBytes/s or more...
If you get a lot less (like, 5 MB/s), you have a problem (DMA disabled,
etc)
