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

 > Subject: Re: Kdump issue with percpu_alloc=lpage
 > From: Vivek Goyal <vgoyal@redhat.com>
 > Date: Tue, 27 Oct 2009 15:24:14 -0400
 > To: "Blackwood, John" <john.blackwood@ccur.com>
 > CC: Tejun Heo <tj@kernel.org>, "kexec@lists.infradead.org" 
<kexec@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 
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.
 >
 > Thanks Tejun. percpu_to_phys() makes sense to me also. John, would you
 > like to post a patch for this.

Hi Vivek,

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.

Thanks.

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

             reply	other threads:[~2009-10-28 21:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-28 21:22 John Blackwood [this message]
2009-11-18  9:25 ` Kdump issue with percpu_alloc=lpage 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
  -- strict thread matches above, loose matches on Subject: below --
2009-10-27 19:16 John Blackwood
2009-10-27 19:24 ` 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=4AE8B612.9080103@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