Hallvard B Furuseth wrote:
Howard Chu writes:
That was to prevent the signal from being lost. Though I suppose it doesn't matter, since the signal would get sent again soon enough.
If it's lost, that'll usually be because memp_trickle() is busily flusing pages. It won't return until it has nothing to do, in which case immediately calling it again won't be very useful.
Right. Perhaps we should remove that mutex lock/unlock.
A few other thoughts:
Could memp_trickle() have a bug so it loses "page is frequently used" info or whatever Berkeley DB is using? Then it could cause such pages to need to be re-read when they'd otherwise not need to be.
I guess that's possible; I haven't really looked at BDB's cache replacement policy. I've always assumed it was simple LRU tho frequency-based would be more useful.
The memp_trickle() call the dirty page percentage to 70%. Might be interesting to see how a run without the trickle task compares to one with trickle + 43% extra DB cache. (1/0.7 = 1.43).
Good idea.
In the first message, Ralf Haferkamp wrote:
I did some profiling (with valgrinds callgrind tool) to find out where all the time is spend and it revealed that 2.4 spend a significantly larger amount of systime in the pwrite() function than 2.3. Most of that seemed to come from the bdb_tool_trickle_task() that calls libdb's memp_trickle() function.
The trickle task takes over write work that is otherwise done from other functions. If it spends as much or more_ time in pwrite() from trickle_task() than it does in pwrite() when there is no trickle task, that'd be interesting...