From: Con Kolivas <kernel@kolivas.org>
To: Andrea Arcangeli <andrea@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] per-task-predictive-write-throttling-1
Date: Thu, 15 Sep 2005 10:44:23 +1000 [thread overview]
Message-ID: <200509151044.24002.kernel@kolivas.org> (raw)
In-Reply-To: <20050914220334.GF4966@opteron.random>
On Thu, 15 Sep 2005 08:03 am, Andrea Arcangeli wrote:
> I wrote a patch to try avoiding making dirty about half the ram of the
> computer when a single task is writing to disk (like during untarring or
> rsyncing). I try to detect how many pages this task wrote durign the
> last dirty_ratio_centisecs (sysctl configurable), and I assume that
> those pages are already dirty (since they'll be soon anyway).
>
> This way a write-hog task will not lock dirty half the cache for no good
> reason and other tasks will be allowed to use the dirty cache to avoid
> blocking during writes. It's not like the write will not be noticeable,
> but it should become substantially more responsive.
>
> I did a basic test to verify that the performance of the write-hog task
> didn't suffer, the bandwidth remains the same (difference of 2 seconds
> over 1 min and 20sec of workload). [though this should be tested in
> other configurations, it may not be stable yet, the dirty level can go
> down to zero to the point of nr_reclaimable reaching 0, hence the check
> needed to avoid locking up in blk_congestion_wait]
>
> /proc/<pid>/future_pages tells about the current prediction.
> /proc/sys/vm/dirty_ratio_centisecs enables/disables the feature, setting
> it to 0 makes the kernel behave like current mainline, no difference,
> setting it close to zero means almost disabled, large values means very
> enabled, a reasonable value is 5 sec, predicting too much in the future
> may not lead the best results in real life as you can guess ;).
Nice idea!
I suspect the reason 5 seconds is good is probably because it's the same value
as dirty_writeback_centisecs.
I think this patch will sit nicely in my tree thanks :).
Cheers,
Con
next prev parent reply other threads:[~2005-09-15 0:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-14 22:03 [PATCH] per-task-predictive-write-throttling-1 Andrea Arcangeli
2005-09-15 0:44 ` Con Kolivas [this message]
2005-09-15 17:14 ` Andrea Arcangeli
2005-09-16 10:42 ` Anton Blanchard
2005-09-16 15:12 ` Andrea Arcangeli
2005-09-15 6:04 ` Nikita Danilov
2005-09-16 15:34 ` Andrea Arcangeli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200509151044.24002.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.