Kdump issue with percpu_alloc=lpage
john.blackwood at ccur.com
Wed Oct 28 17:22:26 EDT 2009
> Subject: Re: Kdump issue with percpu_alloc=lpage
> From: Vivek Goyal <vgoyal at redhat.com>
> Date: Tue, 27 Oct 2009 15:24:14 -0400
> To: "Blackwood, John" <john.blackwood at ccur.com>
> CC: Tejun Heo <tj at kernel.org>, "kexec at lists.infradead.org"
<kexec at lists.infradead.org>
> > > 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
> > > 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().
> > > 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.
> Thanks Tejun. percpu_to_phys() makes sense to me also. John, would you
> like to post a patch for this.
I'm probably not really NUMA/vm savy enough to attempt a patch
for approval at LKML.
But maybe someone else more qualified can take up the cause.
More information about the kexec