> 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.
kflushd() calling refill_freelist() is a scenario which is very likely to
be a deadlock condition. For example, waiting on one locked loop device
buffer might sleep forever, since in order to unlock a loop device buffer
the kernel might need to getblk() a buffer on the real device, which will
need refill_freelist() again..
> 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.
The intention was to wait for some I/O to be actually performed rather
than just queued (using the implicit matching of kflushd()'s speed to
the device speed by get_request_wait() in ll_rw_blk.c when no free request
structure is available). This is a similar effect to sleeping on a locked
buffer, waiting for it to unlock.
Gadi