All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@google.com>,
	ebiederm@xmission.com, mahesh@linux.vnet.ibm.com,
	schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-s390@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [patch v2 2/2] s390: Add architecture code for unmapping crashkernel memory
Date: Wed, 14 Sep 2011 14:29:02 -0400	[thread overview]
Message-ID: <20110914182902.GA32658@redhat.com> (raw)
In-Reply-To: <1315990708.3367.14.camel@br98xy6r>

On Wed, Sep 14, 2011 at 10:58:28AM +0200, Michael Holzheu wrote:
> Hello Andrew,
> 
> On Tue, 2011-09-13 at 14:52 -0700, Andrew Morton wrote:
> > On Tue, 13 Sep 2011 15:26:37 +0200
> > Michael Holzheu <holzheu@linux.vnet.ibm.com> wrote:
> 
> [snip]
> 
> > > --- a/arch/s390/include/asm/kexec.h
> > > +++ b/arch/s390/include/asm/kexec.h
> > > @@ -36,6 +36,9 @@
> > >  /* Allocate one page for the pdp and the second for the code */
> > >  #define KEXEC_CONTROL_PAGE_SIZE 4096
> > >  
> > > +/* Alignment of crashkernel memory */
> > > +#define KEXEC_CRASH_MEM_ALIGN HPAGE_SIZE
> > 
> > Why not make this unconditional, for all architectures which support
> > hugepages?  ie:
> > 
> > #ifdef HPAGE_SIZE
> > #define KEXEC_CRASH_MEM_ALIGN HPAGE_SIZE
> > #else
> > #define KEXEC_CRASH_MEM_ALIGN PAGE_SIZE
> > #endif
> 
> > in include/linux/kexec.h?
> > 
> > IOW, what are the compromises here?
> 
> If we would do it that way, crashkernel memory on architectures that
> support large pages but do not support unmapping of crashkernel memory
> would always be aligned to HPAGE_SIZE. But only PAGE_SIZE alignment
> would be necessary in that case.
> 
> If that is acceptable I have no problem to define that unconditional for
> all architectures. Vivek what do you think?

As PAGE_SIZE alignment is sufficient for rest of the architecture, I 
am fine with keeping it in arch dependent files.

Thanks
Vivek

WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@google.com>,
	linux-s390@vger.kernel.org, mahesh@linux.vnet.ibm.com,
	heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org,
	ebiederm@xmission.com, schwidefsky@de.ibm.com,
	Andrew Morton <akpm@linux-foundation.org>,
	kexec@lists.infradead.org
Subject: Re: [patch v2 2/2] s390: Add architecture code for unmapping crashkernel memory
Date: Wed, 14 Sep 2011 14:29:02 -0400	[thread overview]
Message-ID: <20110914182902.GA32658@redhat.com> (raw)
In-Reply-To: <1315990708.3367.14.camel@br98xy6r>

On Wed, Sep 14, 2011 at 10:58:28AM +0200, Michael Holzheu wrote:
> Hello Andrew,
> 
> On Tue, 2011-09-13 at 14:52 -0700, Andrew Morton wrote:
> > On Tue, 13 Sep 2011 15:26:37 +0200
> > Michael Holzheu <holzheu@linux.vnet.ibm.com> wrote:
> 
> [snip]
> 
> > > --- a/arch/s390/include/asm/kexec.h
> > > +++ b/arch/s390/include/asm/kexec.h
> > > @@ -36,6 +36,9 @@
> > >  /* Allocate one page for the pdp and the second for the code */
> > >  #define KEXEC_CONTROL_PAGE_SIZE 4096
> > >  
> > > +/* Alignment of crashkernel memory */
> > > +#define KEXEC_CRASH_MEM_ALIGN HPAGE_SIZE
> > 
> > Why not make this unconditional, for all architectures which support
> > hugepages?  ie:
> > 
> > #ifdef HPAGE_SIZE
> > #define KEXEC_CRASH_MEM_ALIGN HPAGE_SIZE
> > #else
> > #define KEXEC_CRASH_MEM_ALIGN PAGE_SIZE
> > #endif
> 
> > in include/linux/kexec.h?
> > 
> > IOW, what are the compromises here?
> 
> If we would do it that way, crashkernel memory on architectures that
> support large pages but do not support unmapping of crashkernel memory
> would always be aligned to HPAGE_SIZE. But only PAGE_SIZE alignment
> would be necessary in that case.
> 
> If that is acceptable I have no problem to define that unconditional for
> all architectures. Vivek what do you think?

As PAGE_SIZE alignment is sufficient for rest of the architecture, I 
am fine with keeping it in arch dependent files.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2011-09-14 18:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-13 13:26 [patch v2 0/2] kdump: Allow removal of page tables for crashkernel memory Michael Holzheu
2011-09-13 13:26 ` Michael Holzheu
2011-09-13 13:26 ` [patch v2 1/2] kdump: Add infrastructure for unmapping " Michael Holzheu
2011-09-13 13:26   ` Michael Holzheu
2011-09-13 13:40   ` Vivek Goyal
2011-09-13 13:40     ` Vivek Goyal
2011-09-13 13:26 ` [patch v2 2/2] s390: Add architecture code " Michael Holzheu
2011-09-13 13:26   ` Michael Holzheu
2011-09-13 21:52   ` Andrew Morton
2011-09-13 21:52     ` Andrew Morton
2011-09-14  8:58     ` Michael Holzheu
2011-09-14  8:58       ` Michael Holzheu
2011-09-14 18:29       ` Vivek Goyal [this message]
2011-09-14 18:29         ` Vivek Goyal
2011-09-15  8:48         ` Michael Holzheu
2011-09-15  8:48           ` Michael Holzheu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110914182902.GA32658@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=akpm@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=holzheu@linux.vnet.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mahesh@linux.vnet.ibm.com \
    --cc=schwidefsky@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.