From: "John Stoffel" <john@stoffel.org>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Mike Snitzer <msnitzer@redhat.com>,
John Stoffel <john@stoffel.org>, Tom Yan <tom.ty89@gmail.com>,
dm-devel@redhat.com, Ondrej Kozina <okozina@redhat.com>,
hch@lst.de, Milan Broz <mbroz@redhat.com>
Subject: Re: [PATCH] dm-crypt: limit the number of allocated pages
Date: Mon, 21 Aug 2017 10:06:45 -0400 [thread overview]
Message-ID: <22938.59637.741061.422812@quad.stoffel.home> (raw)
In-Reply-To: <alpine.LRH.2.02.1708181523190.30782@file01.intranet.prod.int.rdu2.redhat.com>
>>>>> "Mikulas" == Mikulas Patocka <mpatocka@redhat.com> writes:
Mikulas> On Fri, 18 Aug 2017, John Stoffel wrote:
Mikulas> The limit can't be changed. I expect that no one will run a system with
Mikulas> such a tight requirements that the memory is used up to the last 2%.
>>
Mikulas> If the user is near hitting the memory limit, he can just add swap space
Mikulas> to solve the problem instead of tuning dm-crypt.
>>
>> My real concern is that we build up too many outstanding BIOs so that
>> they take along time to process. I'm already seeing some reports
>> about timeouts after 120 seconds due to stacking of dm-crypt with
>> other stuff.
>>
>> What I'm trying to say is that as memory grows, you need to slow down
>> the growth of the amount of memory that dm-crypt can allocate. It's
>> more important to scale by the speed of the IO sub-system than the
>> size of memory.
>>
>> But hey, you really addresed my concern with smaller memory systems
>> already.
>>
>> John
Mikulas> This patch doesn't restrict the number of in-flight bios. Lowering the
Mikulas> memory limit has no effect on the number of bios being allocated by some
Mikulas> other part of the kernel and submitted for dm-crypt.
Good to know.
Mikulas> Some times ago I made a patch that limits the number of in-flight bios in
Mikulas> device mapper - see this:
Mikulas> http://people.redhat.com/~mpatocka/patches/kernel/dm-limit-outstanding-bios/
Interesting. I'll try to find some time to look this over.
next prev parent reply other threads:[~2017-08-21 14:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-14 2:45 [PATCH] dm-crypt: limit the number of allocated pages Mikulas Patocka
2017-08-14 20:19 ` John Stoffel
2017-08-15 0:07 ` Mikulas Patocka
2017-08-17 18:50 ` John Stoffel
2017-08-18 16:58 ` Mikulas Patocka
2017-08-18 19:02 ` John Stoffel
2017-08-19 0:18 ` Mikulas Patocka
2017-08-19 0:59 ` Bart Van Assche
2017-08-21 14:06 ` John Stoffel [this message]
2017-08-14 20:22 ` Tom Yan
2017-08-15 0:20 ` Mikulas Patocka
2017-08-15 16:51 ` Tom Yan
2017-08-19 17:34 ` Mikulas Patocka
2017-08-25 4:58 ` Tom Yan
2017-09-11 23:57 ` Mikulas Patocka
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=22938.59637.741061.422812@quad.stoffel.home \
--to=john@stoffel.org \
--cc=dm-devel@redhat.com \
--cc=hch@lst.de \
--cc=mbroz@redhat.com \
--cc=mpatocka@redhat.com \
--cc=msnitzer@redhat.com \
--cc=okozina@redhat.com \
--cc=tom.ty89@gmail.com \
/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.