public inbox for kexec@lists.infradead.org
 help / color / mirror / Atom feed
From: John Blackwood <john.blackwood@ccur.com>
To: Tejun Heo <tj@kernel.org>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: Kdump issue with percpu_alloc=lpage
Date: Tue, 27 Oct 2009 14:16:21 -0500	[thread overview]
Message-ID: <4AE74705.2000707@ccur.com> (raw)


 > Vivek Goyal wrote:
 > > > In kdump, we allocate per cpu area using alloc_percpu() and later
 > > > export the physical address of the area allocated to user space 
through
 > > > sysfs. (/sys/devices/system/cpu/cpuN/crash_notes). kexec-tools 
user space
 > > > utility makes use of this physical address to store in some ELF 
headers
 > > > which in turn are used by the second kernel booted after crash.
 > > >
 > > > We assume that address returned by per_cpu_ptr() is unity mapped and
 > > > use __pa() to convert that address to physical address.
 > > >
 > > > addr = __pa(per_cpu_ptr(crash_notes, cpunum));
 > > >
 > > > Is that not a valid assumption with percpu_alloc=lpage or 
percpu_alloc=4k
 > > > options? If not, what's the right way to get the physical address in
 > > > such situations?
 >
 > The lpage allocator is gone in the latest tree and only "embed" and
 > "page" allocators are there.  The only difference between the two is
 > that the embed one will put the first chunk inside the linearly mapped
 > area which in turn means that __pa() would work on static percpu
 > variables and some of dynamic ones but from the second chunk on and
 > for the page allocator, the percpu addresses will be remapped into
 > vmalloc area and behaves just like any other vmalloc address meaning
 > that the physical page can be determined using vmalloc_to_page().  So,
 > something like the following should work,
 >
 >         v = per_cpu_ptr(crash_notes, cpunum);
 >         if (v < VMALLOC_START || v >= VMALLOC_END)
 >                 p = __pa(v);
 >         else
 >                 p = page_to_phys(vmalloc_to_page(v));
 >
 > For the now removed lpage, it would be a bit difficult and we'll
 > probably need to add a dedicated function to percpu to determine the
 > physical address.  Hmmm... probably the right thing to do is to add
 > such function so that the user can simply call percpu_to_phys()
 > regardless of address?

Hi Tejun,

Just my 2 cent's worth...

I like the idea of having a percpu_to_phys() function that others can
call so that such detail are localized... and this also would tend to
be maintained better over time, since it would be more visible being
located near where the percpu support is implmented.

Thank you for the information.


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

             reply	other threads:[~2009-10-27 19:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-27 19:16 John Blackwood [this message]
2009-10-27 19:24 ` Kdump issue with percpu_alloc=lpage Vivek Goyal
  -- strict thread matches above, loose matches on Subject: below --
2009-10-28 21:22 John Blackwood
2009-11-18  9:25 ` Tejun Heo
2009-11-19 14:33   ` Vivek Goyal
2009-11-19 14:45     ` Tejun Heo
2009-11-19 15:05       ` Vivek Goyal
2009-11-19 15:20         ` John Blackwood
2009-11-19 16:23       ` Vivek Goyal
2009-11-19 16:31         ` Tejun Heo
2009-11-19 16:36           ` Vivek Goyal

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=4AE74705.2000707@ccur.com \
    --to=john.blackwood@ccur.com \
    --cc=kexec@lists.infradead.org \
    --cc=tj@kernel.org \
    --cc=vgoyal@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox