From owner-freebsd-current@FreeBSD.ORG  Mon Sep 27 17:54:21 2010
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 049311065743;
	Mon, 27 Sep 2010 17:54:21 +0000 (UTC) (envelope-from avg@freebsd.org)
Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140])
	by mx1.freebsd.org (Postfix) with ESMTP id 2251A8FC0A;
	Mon, 27 Sep 2010 17:54:18 +0000 (UTC)
Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua
	[212.40.38.101])
	by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA14586;
	Mon, 27 Sep 2010 20:54:17 +0300 (EEST)
	(envelope-from avg@freebsd.org)
Message-ID: <4CA0DA49.2090006@freebsd.org>
Date: Mon, 27 Sep 2010 20:54:17 +0300
From: Andriy Gapon <avg@freebsd.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US;
	rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: freebsd-current@freebsd.org
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Alan Cox <alc@freebsd.org>
Subject: minidump size on amd64
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Sep 2010 17:54:21 -0000


It seems that minidump on amd64 is always dumping at least about 1GB of data
regardless of actual memory size and usage and thus can be even larger than
regular dump.

Specifically, I suspect the following code:
for (va = VM_MIN_KERNEL_ADDRESS; va < MAX(KERNBASE + NKPT * NBPDR,
    kernel_vm_end); va += NBPDR) {
        i = (va >> PDPSHIFT) & ((1ul << NPDPEPGSHIFT) - 1);
        /*
         * We always write a page, even if it is zero. Each
         * page written corresponds to 2MB of space
         */
        ptesize += PAGE_SIZE;

It seems that difference between KERNBASE and VM_MIN_KERNEL_ADDRESS is already
~500G.  Which means 500G divided by 2M equals 250K iterations/pages.  Which is 1GB
of data.

Looks like this came from amd64 KVA expansion.
And it seems a little bit wasteful?

-- 
Andriy Gapon