On Thu, Sep 03, 2009 at 10:22:23AM +0800, Wu Fengguang wrote:
> So I suggested just remove clip_bdi_dirty_limit(). To be sure, could
> run with the following patch and check if big numbers are showed.
>
Simple tests show that clip_bdi_dirty_limit() is no-op with one single
disk and 1-2 dirtier(s):
[...]
[ 720.630917] clip_bdi_dirty_limit 0
[ 720.753865] clip_bdi_dirty_limit 0
[ 720.915198] clip_bdi_dirty_limit 0
[ 721.149511] clip_bdi_dirty_limit 0
[...]
Thanks,
Fengguang
> --- linux-mm.orig/mm/page-writeback.c 2009-09-02 17:16:51.000000000 +0800
> +++ linux-mm/mm/page-writeback.c 2009-09-03 10:19:00.000000000 +0800
> @@ -258,6 +258,7 @@ static void clip_bdi_dirty_limit(struct
> unsigned long dirty, unsigned long *pbdi_dirty)
> {
> unsigned long avail_dirty;
> + unsigned long delta;
>
> avail_dirty = global_page_state(NR_FILE_DIRTY) +
> global_page_state(NR_WRITEBACK) +
> @@ -272,6 +273,11 @@ static void clip_bdi_dirty_limit(struct
> avail_dirty += bdi_stat(bdi, BDI_RECLAIMABLE) +
> bdi_stat(bdi, BDI_WRITEBACK);
>
> + delta = *pbdi_dirty - min(*pbdi_dirty, avail_dirty);
> + delta *= 1024;
> + delta /= *pbdi_dirty + 1;
> + printk("clip_bdi_dirty_limit %lu\n", delta);
> +
> *pbdi_dirty = min(*pbdi_dirty, avail_dirty);
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
