Hi Werner,
If kflushd executes the refill_freelist code (and can't find any
available buffers), the blocking wakeup would be a no-op, since the
daemon is already active. But kflushd would still have to look for
locked buffers and wait on one before using the atomic allocations. It
would be very unlikely not to have any locked buffers -- this would
imply that 100% of the buffers are dirty.
Note that the addition of the non-blocking wakeup is there to forestall
the possibility of getting 100% dirty buffers.
> Next point is: In bdflush() the wake_up(&bdflush_done) statement should
> be moved to be called only once before sleeping again. And to avoid
> a deadlock a check for the _actual_ number of dirty buffers should be
> added. See the corresponding part of patch-2.0.31:
The 2.1.xx series does include the test for ndirty == 0.
For the case of moving the wakeup(&bdflush_done), I remember seeing this
change in 2.0.xx, but don't follow the logic of why this is good. It
seems to me that this would just slow down the system -- it makes the
tasks wait longer when some buffers may already have unlocked and be
available.
Consider the case where kflushd makes several passes. There will be many
blocking operations while writing out 1000's of buffers, and if the
buffers written in the first pass have started to unlock, other tasks
should be allowed to proceed. Moving the wakeup to occur only when
kflushd is finished will then force tasks to wait longer than necessary.
Regards,
Bill