All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Artem S. Tashkinov" <t.artem@lycos.com>
To: torvalds@linux-foundation.org
Cc: fengguang.wu@intel.com, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org
Subject: Re: Disabling in-memory write cache for x86-64 in Linux II
Date: Fri, 25 Oct 2013 08:30:53 +0000 (UTC)	[thread overview]
Message-ID: <1814253454.3449.1382689853825.JavaMail.mail@webmail07> (raw)
In-Reply-To: CA+55aFxj81TRhe1+FJWqER7VVH_z_Sk0+hwtHvniA0ATsF_eKw@mail.gmail.com

Oct 25, 2013 02:18:50 PM, Linus Torvalds wrote:
On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov wrote:
>>
>> On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel
>> built for the i686 (with PAE) and x86-64 architectures. What's really troubling me
>> is that the x86-64 kernel has the following problem:
>>
>> When I copy large files to any storage device, be it my HDD with ext4 partitions
>> or flash drive with FAT32 partitions, the kernel first caches them in memory entirely
>> then flushes them some time later (quite unpredictably though) or immediately upon
>> invoking "sync".
>
>Yeah, I think we default to a 10% "dirty background memory" (and
>allows up to 20% dirty), so on your 16GB machine, we allow up to 1.6GB
>of dirty memory for writeout before we even start writing, and twice
>that before we start *waiting* for it.
>
>On 32-bit x86, we only count the memory in the low 1GB (really
>actually up to about 890MB), so "10% dirty" really means just about
>90MB of buffering (and a "hard limit" of ~180MB of dirty).
>
>And that "up to 3.2GB of dirty memory" is just crazy. Our defaults
>come from the old days of less memory (and perhaps servers that don't
>much care), and the fact that x86-32 ends up having much lower limits
>even if you end up having more memory.
>
>You can easily tune it:
>
>    echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
>    echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes
>
>or similar. But you're right, we need to make the defaults much saner.
>
>Wu? Andrew? Comments?
>

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.

I.e. when I dump a large MySQL database (its dump weighs around 10GB)
- it appears on the disk almost immediately, but then, later, when the kernel
decides to flush it to the disk, the server almost stalls and other IO requests
take a lot more time to complete even though mysqldump is run with ionice -c3,
so the use of ionice has no real effect.

Artem

  reply	other threads:[~2013-10-25  8:30 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-25  7:25 Disabling in-memory write cache for x86-64 in Linux II Artem S. Tashkinov
2013-10-25  7:25 ` Artem S. Tashkinov
2013-10-25  8:18 ` Linus Torvalds
2013-10-25  8:18   ` Linus Torvalds
2013-10-25  8:30   ` Artem S. Tashkinov [this message]
2013-10-25  8:43     ` Linus Torvalds
2013-10-25  9:15       ` Karl Kiniger
2013-10-29 20:30         ` Jan Kara
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-01 14:31               ` Maxim Patlasov
2013-11-04 22:01               ` Andrew Morton
2013-11-04 22:01                 ` Andrew Morton
2013-11-06 14:30                 ` Maxim Patlasov
2013-11-06 14:30                   ` Maxim Patlasov
2013-11-06 15:05                 ` [PATCH] mm: add strictlimit knob -v2 Maxim Patlasov
2013-11-06 15:05                   ` Maxim Patlasov
2013-11-07 12:26                   ` Henrique de Moraes Holschuh
2013-11-07 12:26                     ` Henrique de Moraes Holschuh
2013-11-22 23:45                   ` Andrew Morton
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  0:50     ` Andreas Dilger
2013-11-05  4:12     ` Dave Chinner
2013-11-05  4:12       ` Dave Chinner
2013-11-05  4:12       ` Dave Chinner
2013-11-07 13:48       ` Jan Kara
2013-11-07 13:48         ` Jan Kara
2013-11-07 13:48         ` Jan Kara
2013-11-11  3:22         ` Dave Chinner
2013-11-11  3:22           ` Dave Chinner
2013-11-11  3:22           ` Dave Chinner
2013-11-11 19:31           ` Jan Kara
2013-11-11 19:31             ` Jan Kara
2013-11-05  6:32   ` Figo.zhang
2013-10-25 10:49 ` NeilBrown
2013-10-25 11:26   ` David Lang
2013-10-25 11:26     ` David Lang
2013-10-25 18:26     ` Artem S. Tashkinov
2013-10-25 18:26       ` Artem S. Tashkinov
2013-10-25 19:40       ` Diego Calleja
2013-10-25 19:40         ` Diego Calleja
2013-10-25 23:32         ` Fengguang Wu
2013-10-25 23:32           ` Fengguang Wu
2013-10-25 23:32           ` Fengguang Wu
2013-11-15 15:48           ` Diego Calleja
2013-11-15 15:48             ` Diego Calleja
2013-10-25 20:43       ` NeilBrown
2013-10-25 21:03         ` Artem S. Tashkinov
2013-10-25 21:03           ` Artem S. Tashkinov
2013-10-25 22:11           ` NeilBrown
2013-11-05  1:40             ` Figo.zhang
2013-11-05  1:47               ` David Lang
2013-11-05  1:47                 ` David Lang
2013-11-05  2:08               ` NeilBrown
2013-10-29 20:49       ` Jan Kara
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=1814253454.3449.1382689853825.JavaMail.mail@webmail07 \
    --to=t.artem@lycos.com \
    --cc=akpm@linux-foundation.org \
    --cc=fengguang.wu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.