PFC wrote: > > 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 !!!
I agree that smoothness needs working on. After we merge. > > 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) > > > > PFC is right.
