From: Jan Kara <firstname.lastname@example.org> To: Karl Kiniger <email@example.com> Cc: Linus Torvalds <firstname.lastname@example.org>, "Artem S. Tashkinov" <email@example.com>, Wu Fengguang <firstname.lastname@example.org>, Andrew Morton <email@example.com>, Linux Kernel Mailing List <firstname.lastname@example.org> Subject: Re: Disabling in-memory write cache for x86-64 in Linux II Date: Tue, 29 Oct 2013 21:30:50 +0100 [thread overview] Message-ID: <20131029203050.GE9568@quack.suse.cz> (raw) In-Reply-To: <20131025091555.GA30895@kipc2.localdomain> On Fri 25-10-13 11:15:55, Karl Kiniger wrote: > On Fri 131025, Linus Torvalds wrote: > > On Fri, Oct 25, 2013 at 9:30 AM, Artem S. Tashkinov <email@example.com> wrote: > > > > > > My feeling is that vm.dirty_ratio/vm.dirty_background_ratio should _not_ be > > > percentage based, 'cause for PCs/servers with a lot of memory (say 64GB or > > > more) this value becomes unrealistic (13GB) and I've already had some > > > unpleasant effects due to it. > > > > Right. The percentage notion really goes back to the days when we > > typically had 8-64 *megabytes* of memory So if you had a 8MB machine > > you wouldn't want to have more than one megabyte of dirty data, but if > > you were "Mr Moneybags" and could afford 64MB, you might want to have > > up to 8MB dirty!! > > > > Things have changed. > > > > So I would suggest we change the defaults. Or pwehaps make the rule be > > that "the ratio numbers are 'ratio of memory up to 1GB'", to make the > > semantics similar across 32-bit HIGHMEM machines and 64-bit machines. > > > > The modern way of expressing the dirty limits are to give the actual > > absolute byte amounts, but we default to the legacy ratio mode.. > > > > Linus > > Is it currently possible to somehow set above values per block device? Yes, to some extent. You can set /sys/block/<device>/bdi/max_ratio to the maximum proportion the device's dirty data can take from the total amount. The caveat currently is that this setting only takes effect after we have more than (dirty_background_ratio + dirty_ratio)/2 dirty data in total because that is an amount of dirty data when we start to throttle processes. So if the device you'd like to limit is the only one which is currently written to, the limiting doesn't have a big effect. Andrew has queued up a patch series from Maxim Patlasov which removes this caveat but currently we don't have a way admin can switch that from userspace. But I'd like to have that tunable from userspace exactly for the cases as you describe below. > I want default behaviour for almost everything but DVD drives in DVD+RW > packet writing mode may easily take several minutes in case of a sync. Honza -- Jan Kara <firstname.lastname@example.org> SUSE Labs, CR
next prev parent reply other threads:[~2013-10-29 20:30 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-10-25 7:25 Artem S. Tashkinov 2013-10-25 8:18 ` Linus Torvalds 2013-10-25 8:30 ` Artem S. Tashkinov 2013-10-25 8:43 ` Linus Torvalds 2013-10-25 9:15 ` Karl Kiniger 2013-10-29 20:30 ` Jan Kara [this message] 2013-10-29 20:43 ` Andrew Morton 2013-10-29 21:30 ` Jan Kara 2013-10-29 21:36 ` Linus Torvalds 2013-10-31 14:26 ` Karl Kiniger 2013-11-01 14:25 ` Maxim Patlasov 2013-11-01 14:31 ` [PATCH] mm: add strictlimit knob Maxim Patlasov 2013-11-04 22:01 ` Andrew Morton 2013-11-06 14:30 ` Maxim Patlasov 2013-11-06 15:05 ` [PATCH] mm: add strictlimit knob -v2 Maxim Patlasov 2013-11-07 12:26 ` Henrique de Moraes Holschuh 2013-11-22 23:45 ` Andrew Morton 2013-10-25 11:28 ` Disabling in-memory write cache for x86-64 in Linux II David Lang 2013-10-25 9:18 ` Theodore Ts'o 2013-10-25 9:29 ` Andrew Morton 2013-10-25 9:32 ` Linus Torvalds 2013-10-26 11:32 ` Pavel Machek 2013-10-26 20:03 ` Linus Torvalds 2013-10-29 20:57 ` Jan Kara 2013-10-29 21:33 ` Linus Torvalds 2013-10-29 22:13 ` Jan Kara 2013-10-29 22:42 ` Linus Torvalds 2013-11-01 17:22 ` Fengguang Wu 2013-11-04 12:19 ` Pavel Machek 2013-11-04 12:26 ` Pavel Machek 2013-10-30 12:01 ` Mel Gorman 2013-11-19 17:17 ` Rob Landley 2013-11-20 20:52 ` One Thousand Gnomes 2013-10-25 22:37 ` Fengguang Wu 2013-10-25 23:05 ` Fengguang Wu 2013-10-25 23:37 ` Theodore Ts'o 2013-10-29 20:40 ` Jan Kara 2013-10-30 10:07 ` Artem S. Tashkinov 2013-10-30 15:12 ` Jan Kara 2013-11-05 0:50 ` Andreas Dilger 2013-11-05 4:12 ` Dave Chinner 2013-11-07 13:48 ` Jan Kara 2013-11-11 3:22 ` Dave Chinner 2013-11-11 19:31 ` Jan Kara 2013-10-25 10:49 ` NeilBrown 2013-10-25 11:26 ` David Lang 2013-10-25 18:26 ` Artem S. Tashkinov 2013-10-25 19:40 ` Diego Calleja 2013-10-25 23:32 ` Fengguang Wu 2013-11-15 15:48 ` Diego Calleja 2013-10-25 20:43 ` NeilBrown 2013-10-25 21:03 ` Artem S. Tashkinov 2013-10-25 22:11 ` NeilBrown [not found] ` <CAF7GXvpJVLYDS5NfH-NVuN9bOJjAS5c1MQqSTjoiVBHJt6bWcw@mail.gmail.com> 2013-11-05 1:47 ` David Lang 2013-11-05 2:08 ` NeilBrown 2013-10-29 20:49 ` Jan Kara
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=20131029203050.GE9568@quack.suse.cz \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Disabling in-memory write cache for x86-64 in Linux II' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).