Date: Wed, 29 Sep 2010 23:41:46 +0300 From: Andriy Gapon <avg@freebsd.org> To: freebsd-current@freebsd.org Cc: Alan Cox <alc@freebsd.org> Subject: Re: minidump size on amd64 Message-ID: <4CA3A48A.5070300@freebsd.org> In-Reply-To: <4CA0DA49.2090006@freebsd.org> References: <4CA0DA49.2090006@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 27/09/2010 20:54 Andriy Gapon said the following:
>
> 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?
So perhaps we need to add another level of indirection?
I.e. first dump contiguous array of "pseudo-pde" entries that would point to
chunks of "pseudo-pte" entries, so that "pseudo-pte" entries could be sparse.
This is instead of dumping 1GB of contiguous "pseudo-ptes" as we do now.
A bit of work, though.
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CA3A48A.5070300>