All of lore.kernel.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 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.