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.
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.
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).
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...