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 05/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, Andrew Morton <akpm@linux-foundation.org>
References: <20191127175055.1351403-1-jim.cromie@gmail.com>
From:   Rasmus Villemoes <linux@rasmusvillemoes.dk>
Message-ID: <0f373a8c-8301-41d9-e042-cfe0cef4bd25@rasmusvillemoes.dk>
Date:   Thu, 28 Nov 2019 09:21:28 +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: <20191127175055.1351403-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 27/11/2019 18.50, Jim Cromie wrote:
> during dyndbg init, verbose logging prints its ram overhead.  It
> counted strlens of struct _ddebug's 4 string members, in all callsite
> entries, which would be approximately correct if each had been
> mallocd.  But they are pointers into shared .rodata; for example, all
> 10 kobject callsites have identical filename, module values.
> 
> Its best not to count that memory at all, since we cannot know they
> were linked in because of CONFIG_DYNAMIC_DEBUG=y, and we want to
> report a number that reflects what ram is saved by deconfiguring it.

That, and we avoid 1000s of (mostly cache-cold) strlen() calls during boot.

Acked-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>

I'll see if I can find time to review the other patches, then I think
you need to resend with Andrew on the cc-list (added here). I think he's
the one routing lib/dynamic_debug.c patches.

Rasmus