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
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...
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/