On Fri, Feb 20 2004, Miquel van Smoorenburg wrote: > > > Even if it isn't happening > > > a lot, and something isn't bust it might be a good idea to > > > do this. > > > > Seems OK from a quick check. pdflush will block in get_request_wait() > > occasionally, but not at all often. Perhaps we could move the > > write_congested test into the mpage_writepages() inner loop but it hardly > > seems worth the risk. > > > > Maybe things are different on Miquel's clockwork controller. > > I haven't tested it yet because of the "This patch isn't actually so good" > comment, but I found another explanation. > > > drivers/block/ll_rw_blk.c | 2 ++ > > fs/fs-writeback.c | 2 ++ > > 2 files changed, 4 insertions(+) > > *Lightbulb on* .. I just read fs-writeback.c. As I said, this happens > with an LVM device. Could it be that because LVM and the actual device > have different struct request_queue's things go awry ? > > In fs-writeback.c, your're looking at the LVM device (and its > request_queue, and its backing_dev_info). In__make_request, you're > looking at the SCSI device. In principle, the lvm/md queues themselves will never be congested. But the underlying queues can be, of course. Now this approach is _much_ better, imo. I don't particularly care very much for how you solved it, though, I'd much rather just see both setting and testing passed down (and kill the ->aux as well). Regardless of the initial hw depth vs block depth (which is also a generic device problem, not just dm related), this would be a good addition to the congestion logic. -- Jens Axboe _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
