Re: [PATCH 10/10] mm: per device dirty threshold
From: Peter Zijlstra
Date: Tue Apr 24 2007 - 05:27:25 EST
On Tue, 2007-04-24 at 11:14 +0200, Miklos Szeredi wrote:
> > > I'm still not quite sure what purpose the above "soft" limiting
> > > serves. It seems to just give advantage to writers, which managed to
> > > accumulate lots of dirty pages, and then can convert that into even
> > > more dirtyings.
> > The queues only limit the actual in-flight writeback pages,
> > balance_dirty_pages() considers all pages that might become writeback as
> > well as those that are.
> > > Would it make sense to remove this behavior, and ensure that
> > > balance_dirty_pages() doesn't return until the per-queue limits have
> > > been complied with?
> > I don't think that will help, balance_dirty_pages drives the queues.
> > That is, it converts pages from mere dirty to writeback.
> Yes. But current logic says, that if you convert "write_chunk" dirty
> to writeback, you are allowed to dirty "ratelimit" more.
> D: number of dirty pages
> W: number of writeback pages
> L: global limit
> C: write_chunk = ratelimit_pages * 1.5
> R: ratelimit
> If D+W >= L, then R = 8
> Let's assume, that D == L and W == 0. And that all of the dirty pages
> belong to a single device. Also for simplicity, lets assume an
> infinite length queue, and a slow device.
> Then while converting the dirty pages to writeback, D / C * R new
> dirty pages can be created. So when all existing dirty have been
> D = L / C * R
> W = L
> D + W = L * (1 + R / C)
> So we see, that we're now even more above the limit than before the
> conversion. This means, that we starve writers to other devices,
> which don't have as many dirty pages, because until the slow device
> doesn't finish these writes they will not get to do anything.
> Your patch helps this in that if the other writers have an empty queue
> and no dirty, they will be allowed to slowly start writing. But they
> will not gain their full share until the slow dirty-hog goes below the
> global limit, which may take some time.
> So I think the logical thing to do, is if the dirty-hog is over it's
> queue limit, don't let it dirty any more until it's dirty+writeback go
> below the limit. That allowes other devices to more quickly gain
> their share of dirty pages.
Ahh, now I see; I had totally blocked out these few lines:
pages_written += write_chunk - wbc.nr_to_write;
if (pages_written >= write_chunk)
break; /* We've done our duty */
yeah, those look dubious indeed... And reading back Neil's comments, I
think he agrees.
Shall we just kill those?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/