On Wed, 2009-02-11 at 14:45 -0800, Andrew Morton wrote:
> On Wed, 11 Feb 2009 17:22:47 +0900 (JST)
> KOSAKI Motohiro wrote:
>
> > > I want to put into powerpc-next patches relying into that, so if the
> > > patch is ok with you guys, can I stick it in powerpc.git ?
> >
> > hm.
> > Generally, all
> On Wed, 11 Feb 2009 17:22:47 +0900 (JST)
> KOSAKI Motohiro wrote:
>
> > > I want to put into powerpc-next patches relying into that, so if the
> > > patch is ok with you guys, can I stick it in powerpc.git ?
> >
> > hm.
> > Generally, all MM patch should merge into -mm tree at first.
> > but I
On Wed, 11 Feb 2009 17:22:47 +0900 (JST)
KOSAKI Motohiro wrote:
> > I want to put into powerpc-next patches relying into that, so if the
> > patch is ok with you guys, can I stick it in powerpc.git ?
>
> hm.
> Generally, all MM patch should merge into -mm tree at first.
> but I don't think this
> We have get_vm_area_caller() and __get_vm_area() but not
> __get_vm_area_caller()
>
> On powerpc, I use __get_vm_area() to separate the ranges of addresses given
> to vmalloc vs. ioremap (various good reasons for that) so in order to be
> able to implement the new caller tracking in /proc/vmall
We have get_vm_area_caller() and __get_vm_area() but not __get_vm_area_caller()
On powerpc, I use __get_vm_area() to separate the ranges of addresses given
to vmalloc vs. ioremap (various good reasons for that) so in order to be
able to implement the new caller tracking in /proc/vmallocinfo, I nee
