Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 06/16] dyndbg: fix overcounting of ram used by dyndbg
To:     Jim Cromie <jim.cromie@gmail.com>, jbaron@akamai.com,
        linux-kernel@vger.kernel.org
Cc:     greg@kroah.com
References: <20191029200035.9889-1-jim.cromie@gmail.com>
From:   Rasmus Villemoes <linux@rasmusvillemoes.dk>
Message-ID: <ec6fba26-c384-a29d-eee9-4f0e56c3af06@rasmusvillemoes.dk>
Date:   Tue, 29 Oct 2019 21:47:40 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20191029200035.9889-1-jim.cromie@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 29/10/2019 21.00, Jim Cromie wrote:
> during dyndbg init, verbose logging prints its ram overhead.  But it
> counted strlens of all ddebug callsite entries, which are full of
> pointers into shared __dyndbg memory, and shouldnt be counted at all
> (since theyre already in the __dyndbg section)

Hm. I agree we're probably overcounting, but the strings themselves do
not live in __dyndbg, but in .rodata. It's true that __FILE__ (and maybe
in a few cases ->format) get's deduplicated and by the nature of
__func__, ->function points at a unique-per-function string.

So I think the commit log is a bit misleading. However, I think the
patch is a good idea anyway: avoiding 4N strlen() calls during boot is a
good thing. And if anybody wants to know how much memory is used by the
pointed-to-strings, well, "wc dynamic_debug/control" should give an idea.

Rasmus