From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753250AbdD0Fo3 (ORCPT ); Thu, 27 Apr 2017 01:44:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55428 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752693AbdD0FoU (ORCPT ); Thu, 27 Apr 2017 01:44:20 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A174E6330D Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dyoung@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A174E6330D Date: Thu, 27 Apr 2017 13:44:09 +0800 From: Dave Young To: xlpang@redhat.com Cc: Juergen Gross , linux-s390@vger.kernel.org, linux-ia64@vger.kernel.org, Baoquan He , Petr Tesarik , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Eric Biederman , Hari Bathini , akpm@linux-foundation.org, Michael Holzheu Subject: Re: [PATCH v4 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section Message-ID: <20170427054409.GA14079@dhcp-128-65.nay.redhat.com> References: <1492688374-27903-1-git-send-email-xlpang@redhat.com> <20170426071916.GD5381@dhcp-128-65.nay.redhat.com> <59006DAB.8030908@redhat.com> <59007405.6070107@redhat.com> <20170427030607.GB10602@dhcp-128-65.nay.redhat.com> <590180AF.3030202@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <590180AF.3030202@redhat.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 27 Apr 2017 05:44:19 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Xunlei, On 04/27/17 at 01:25pm, Xunlei Pang wrote: > On 04/27/2017 at 11:06 AM, Dave Young wrote: > > [snip] > >>>>> > >>>>> static int __init crash_save_vmcoreinfo_init(void) > >>>>> { > >>>>> + /* One page should be enough for VMCOREINFO_BYTES under all archs */ > >>>> Can we add a comment in the VMCOREINFO_BYTES header file about the one > >>>> page assumption? > >>>> > >>>> Or just define the VMCOREINFO_BYTES as PAGE_SIZE instead of 4096 > >>> Yes, I considered this before, but VMCOREINFO_BYTES is also used by VMCOREINFO_NOTE_SIZE > >>> definition which is exported to sysfs, also some platform has larger page size(64KB), so > >>> I didn't touch this 4096 value. > >>> > >>> I think I should use kmalloc() to allocate both of them, then move this comment to Patch3 > >>> kimage_crash_copy_vmcoreinfo(). > >> But on the other hand, using a separate page for them seems safer compared with > >> using frequently-used slab, what's your opinion? > > I feel current page based way is better. > > > > For 64k page the vmcore note size will increase it seems fine. Do you > > have concern in mind? > > Since tools are supposed to acquire vmcoreinfo note size from sysfs, it should be safe to do so, > except that there is some waste in memory for larger PAGE_SIZE. Either way is fine to me, I think it is up to your implementation, if choose page alloc then modify the macro with PAGE_SIZE looks better. Thanks Dave