From: Robin Murphy <robin.murphy@arm.com>
To: Eric Dumazet <edumazet@google.com>
Cc: Christoph Hellwig <hch@lst.de>, Joerg Roedel <jroedel@suse.de>,
iommu@lists.linux-foundation.org,
Eric Dumazet <eric.dumazet@gmail.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] dma-debug: dynamic allocation of hash table
Date: Fri, 31 Jan 2020 17:43:45 +0000 [thread overview]
Message-ID: <62e1ee46-ad9e-988f-a2a3-8fd217e28f24@arm.com> (raw)
In-Reply-To: <CANn89iKfA+yPHiL4R7-jkewwhDgM6jkwhW5o9H=VL9CnyBikhw@mail.gmail.com>
On 31/01/2020 2:42 pm, Eric Dumazet wrote:
> On Fri, Jan 31, 2020 at 4:30 AM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> ...and when that represents ~5% of the total system RAM it is a *lot*
>> less reasonable than even 12KB. As I said, it's great to make a debug
>> option more efficient such that what it observes is more representative
>> of the non-debug behaviour, but it mustn't come at the cost of making
>> the entire option unworkable for other users.
>>
>
> Then I suggest you send a patch to reduce PREALLOC_DMA_DEBUG_ENTRIES
> because having 65536 preallocated entries consume 4 MB of memory.
...unless it's overridden on the command-line ;)
> Actually this whole attempt to re-implement slab allocations in this
> file is suspect.
Again that's a matter of expected usage patterns - typically the
"reasonable default" or user-defined preallocation should still be
enough (as it *had* to be before), and the kind of systems that can
sustain so many live mappings as to regularly hit the dynamic expansion
path are also likely to have enough memory not to care that later-unused
entries never get 'properly' freed back to the kernel (plus as you've
observed, many workloads tend to reach a steady state where entries are
mostly only transiently free anyway). The reasoning for the exact
implementation details is there in the commit logs.
> Do not get me wrong, but if you really want to run linux on a 16MB host,
> I guess you need to add CONFIG_BASE_SMALL all over the places,
> not only in this kernel/dma/debug.c file.
Right, nobody's suggesting that defconfig should "just work" on your
router/watch/IoT shoelaces/whatever, I'm just saying that tuning any
piece of common code for datacenter behemoths, for quality-of-life
rather than functional necessity, and leaving no way to adjust it other
than hacking the source, would represent an unnecessary degree of
short-sightedness that we can and should avoid.
Taking a closer look at the code, it appears fairly straightforward to
make the hash size variable, and in fact making it self-adjusting
doesn't seem too big a jump from there. I'm happy to have a go at that
myself if you like.
Robin.
next prev parent reply other threads:[~2020-01-31 17:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-30 19:10 [PATCH] dma-debug: dynamic allocation of hash table Eric Dumazet
2020-01-30 23:46 ` Robin Murphy
2020-01-31 0:17 ` Eric Dumazet
2020-01-31 12:30 ` Robin Murphy
2020-01-31 14:42 ` Eric Dumazet
2020-01-31 17:43 ` Robin Murphy [this message]
2020-01-31 17:46 ` Eric Dumazet
2020-02-01 0:06 ` Robin Murphy
2020-01-31 9:06 ` Geert Uytterhoeven
2020-01-31 11:33 ` Robin Murphy
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=62e1ee46-ad9e-988f-a2a3-8fd217e28f24@arm.com \
--to=robin.murphy@arm.com \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=geert@linux-m68k.org \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=jroedel@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 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).