Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

( Expanding cc list, original thread is at
  http://thread.gmane.org/gmane.linux.kernel/1518046 )

Hello,

On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
> Unfortunately, that has not been true on ARM - it's very common for
> there to be an offset on physical memory, sometimes of the order of
> 3GB or more.  This is because on reset, ARMs start executing the code
> at physical address zero, which therefore can't be RAM - and there's
> a desire to avoid complex switching games in hardware to temporarily
> map ROM there instead of RAM.
> 
> On these SoCs which Santosh is working on, the main physical memory
> mapping is above 4GB, with just a small alias below 4GB to allow the
> system to boot without the MMU being on, as they may have more than
> 4GB of RAM.  As I understand it, the small alias below 4GB is not
> suitable for use as a "lowmem" mapping.

Ah, okay, so the @limit which is in physical address can be over 4GB
even for lowmem mappings and alloc_bootmem takes them in ulongs,
urghhh....

Given that still about half of the archs aren't using memblock yet, I
think there are three options.

1. Converting all bootmem interface to use physaddr_t.  But that's
   what memblock is.

2. Introducing new interface.  Easier right now but the danger there
   is that it might end up duplicating most of alloc_bootmem()
   interface anyway and we'll have yet another variant of early mem
   allocator to enjoy.

3. Make all generic code use memblock interface instead of bootmem and
   implement memblock wrapper on archs which don't use memblock yet.
   We'll probably need to sort out different combinations of
   HAVE_MEMBLOCK and NO_BOOTMEM.  If this is doable, it probably is
   the most future proof way.  While it adds new memblock interface
   built on top of bootmem, it would also allow removing the bootmem
   interface built on top of memblock - ie. nobootmem.c, which
   probably is what we should have done from the beginning.

What do you guys think?

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

( Expanding cc list, original thread is at
  http://thread.gmane.org/gmane.linux.kernel/1518046 )

Hello,

On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
> Unfortunately, that has not been true on ARM - it's very common for
> there to be an offset on physical memory, sometimes of the order of
> 3GB or more.  This is because on reset, ARMs start executing the code
> at physical address zero, which therefore can't be RAM - and there's
> a desire to avoid complex switching games in hardware to temporarily
> map ROM there instead of RAM.
> 
> On these SoCs which Santosh is working on, the main physical memory
> mapping is above 4GB, with just a small alias below 4GB to allow the
> system to boot without the MMU being on, as they may have more than
> 4GB of RAM.  As I understand it, the small alias below 4GB is not
> suitable for use as a "lowmem" mapping.

Ah, okay, so the @limit which is in physical address can be over 4GB
even for lowmem mappings and alloc_bootmem takes them in ulongs,
urghhh....

Given that still about half of the archs aren't using memblock yet, I
think there are three options.

1. Converting all bootmem interface to use physaddr_t.  But that's
   what memblock is.

2. Introducing new interface.  Easier right now but the danger there
   is that it might end up duplicating most of alloc_bootmem()
   interface anyway and we'll have yet another variant of early mem
   allocator to enjoy.

3. Make all generic code use memblock interface instead of bootmem and
   implement memblock wrapper on archs which don't use memblock yet.
   We'll probably need to sort out different combinations of
   HAVE_MEMBLOCK and NO_BOOTMEM.  If this is doable, it probably is
   the most future proof way.  While it adds new memblock interface
   built on top of bootmem, it would also allow removing the bootmem
   interface built on top of memblock - ie. nobootmem.c, which
   probably is what we should have done from the beginning.

What do you guys think?

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[H. Peter Anvin]

3 makes sense to me.

Tejun Heo <tj@kernel.org> wrote:

>( Expanding cc list, original thread is at
>  http://thread.gmane.org/gmane.linux.kernel/1518046 )
>
>Hello,
>
>On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux
>wrote:
>> Unfortunately, that has not been true on ARM - it's very common for
>> there to be an offset on physical memory, sometimes of the order of
>> 3GB or more.  This is because on reset, ARMs start executing the code
>> at physical address zero, which therefore can't be RAM - and there's
>> a desire to avoid complex switching games in hardware to temporarily
>> map ROM there instead of RAM.
>> 
>> On these SoCs which Santosh is working on, the main physical memory
>> mapping is above 4GB, with just a small alias below 4GB to allow the
>> system to boot without the MMU being on, as they may have more than
>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>> suitable for use as a "lowmem" mapping.
>
>Ah, okay, so the @limit which is in physical address can be over 4GB
>even for lowmem mappings and alloc_bootmem takes them in ulongs,
>urghhh....
>
>Given that still about half of the archs aren't using memblock yet, I
>think there are three options.
>
>1. Converting all bootmem interface to use physaddr_t.  But that's
>   what memblock is.
>
>2. Introducing new interface.  Easier right now but the danger there
>   is that it might end up duplicating most of alloc_bootmem()
>   interface anyway and we'll have yet another variant of early mem
>   allocator to enjoy.
>
>3. Make all generic code use memblock interface instead of bootmem and
>   implement memblock wrapper on archs which don't use memblock yet.
>   We'll probably need to sort out different combinations of
>   HAVE_MEMBLOCK and NO_BOOTMEM.  If this is doable, it probably is
>   the most future proof way.  While it adds new memblock interface
>   built on top of bootmem, it would also allow removing the bootmem
>   interface built on top of memblock - ie. nobootmem.c, which
>   probably is what we should have done from the beginning.
>
>What do you guys think?
>
>Thanks.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[H. Peter Anvin]

3 makes sense to me.

Tejun Heo <tj@kernel.org> wrote:

>( Expanding cc list, original thread is at
>  http://thread.gmane.org/gmane.linux.kernel/1518046 )
>
>Hello,
>
>On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux
>wrote:
>> Unfortunately, that has not been true on ARM - it's very common for
>> there to be an offset on physical memory, sometimes of the order of
>> 3GB or more.  This is because on reset, ARMs start executing the code
>> at physical address zero, which therefore can't be RAM - and there's
>> a desire to avoid complex switching games in hardware to temporarily
>> map ROM there instead of RAM.
>> 
>> On these SoCs which Santosh is working on, the main physical memory
>> mapping is above 4GB, with just a small alias below 4GB to allow the
>> system to boot without the MMU being on, as they may have more than
>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>> suitable for use as a "lowmem" mapping.
>
>Ah, okay, so the @limit which is in physical address can be over 4GB
>even for lowmem mappings and alloc_bootmem takes them in ulongs,
>urghhh....
>
>Given that still about half of the archs aren't using memblock yet, I
>think there are three options.
>
>1. Converting all bootmem interface to use physaddr_t.  But that's
>   what memblock is.
>
>2. Introducing new interface.  Easier right now but the danger there
>   is that it might end up duplicating most of alloc_bootmem()
>   interface anyway and we'll have yet another variant of early mem
>   allocator to enjoy.
>
>3. Make all generic code use memblock interface instead of bootmem and
>   implement memblock wrapper on archs which don't use memblock yet.
>   We'll probably need to sort out different combinations of
>   HAVE_MEMBLOCK and NO_BOOTMEM.  If this is doable, it probably is
>   the most future proof way.  While it adds new memblock interface
>   built on top of bootmem, it would also allow removing the bootmem
>   interface built on top of memblock - ie. nobootmem.c, which
>   probably is what we should have done from the beginning.
>
>What do you guys think?
>
>Thanks.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Yinghai Lu]

On Sat, Jun 29, 2013 at 10:57 AM, Tejun Heo <tj@kernel.org> wrote:
> ( Expanding cc list, original thread is at
>   http://thread.gmane.org/gmane.linux.kernel/1518046 )
>
> Hello,
>
> On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
>> Unfortunately, that has not been true on ARM - it's very common for
>> there to be an offset on physical memory, sometimes of the order of
>> 3GB or more.  This is because on reset, ARMs start executing the code
>> at physical address zero, which therefore can't be RAM - and there's
>> a desire to avoid complex switching games in hardware to temporarily
>> map ROM there instead of RAM.
>>
>> On these SoCs which Santosh is working on, the main physical memory
>> mapping is above 4GB, with just a small alias below 4GB to allow the
>> system to boot without the MMU being on, as they may have more than
>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>> suitable for use as a "lowmem" mapping.

is that 32bit ARM or 64bit ARM?

>
> Ah, okay, so the @limit which is in physical address can be over 4GB
> even for lowmem mappings and alloc_bootmem takes them in ulongs,
> urghhh....
>
> Given that still about half of the archs aren't using memblock yet, I
> think there are three options.
>
> 1. Converting all bootmem interface to use physaddr_t.  But that's
>    what memblock is.
>
> 2. Introducing new interface.  Easier right now but the danger there
>    is that it might end up duplicating most of alloc_bootmem()
>    interface anyway and we'll have yet another variant of early mem
>    allocator to enjoy.
>
> 3. Make all generic code use memblock interface instead of bootmem and
>    implement memblock wrapper on archs which don't use memblock yet.
>    We'll probably need to sort out different combinations of
>    HAVE_MEMBLOCK and NO_BOOTMEM.  If this is doable, it probably is
>    the most future proof way.  While it adds new memblock interface
>    built on top of bootmem, it would also allow removing the bootmem
>    interface built on top of memblock - ie. nobootmem.c, which
>    probably is what we should have done from the beginning.
>
> What do you guys think?

2. looks more simple.
but will use alloc_memblock as interface.

We don't need to use __alloc_memory_core_early() directly, right?

Thanks

Yinghai

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Russell King - ARM Linux]

On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
> On Sat, Jun 29, 2013 at 10:57 AM, Tejun Heo <tj@kernel.org> wrote:
> > ( Expanding cc list, original thread is at
> >   http://thread.gmane.org/gmane.linux.kernel/1518046 )
> >
> > Hello,
> >
> > On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
> >> Unfortunately, that has not been true on ARM - it's very common for
> >> there to be an offset on physical memory, sometimes of the order of
> >> 3GB or more.  This is because on reset, ARMs start executing the code
> >> at physical address zero, which therefore can't be RAM - and there's
> >> a desire to avoid complex switching games in hardware to temporarily
> >> map ROM there instead of RAM.
> >>
> >> On these SoCs which Santosh is working on, the main physical memory
> >> mapping is above 4GB, with just a small alias below 4GB to allow the
> >> system to boot without the MMU being on, as they may have more than
> >> 4GB of RAM.  As I understand it, the small alias below 4GB is not
> >> suitable for use as a "lowmem" mapping.
> 
> is that 32bit ARM or 64bit ARM?

Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Russell King - ARM Linux]

On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
> On Sat, Jun 29, 2013 at 10:57 AM, Tejun Heo <tj@kernel.org> wrote:
> > ( Expanding cc list, original thread is at
> >   http://thread.gmane.org/gmane.linux.kernel/1518046 )
> >
> > Hello,
> >
> > On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
> >> Unfortunately, that has not been true on ARM - it's very common for
> >> there to be an offset on physical memory, sometimes of the order of
> >> 3GB or more.  This is because on reset, ARMs start executing the code
> >> at physical address zero, which therefore can't be RAM - and there's
> >> a desire to avoid complex switching games in hardware to temporarily
> >> map ROM there instead of RAM.
> >>
> >> On these SoCs which Santosh is working on, the main physical memory
> >> mapping is above 4GB, with just a small alias below 4GB to allow the
> >> system to boot without the MMU being on, as they may have more than
> >> 4GB of RAM.  As I understand it, the small alias below 4GB is not
> >> suitable for use as a "lowmem" mapping.
> 
> is that 32bit ARM or 64bit ARM?

Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Yinghai Lu]

On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>> >> On these SoCs which Santosh is working on, the main physical memory
>> >> mapping is above 4GB, with just a small alias below 4GB to allow the
>> >> system to boot without the MMU being on, as they may have more than
>> >> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>> >> suitable for use as a "lowmem" mapping.
>>
>> is that 32bit ARM or 64bit ARM?
>
> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.

32bit ARM does not support NO_BOOTMEM yet.

arch/arc/Kconfig:       select NO_BOOTMEM
arch/arm64/Kconfig:     select NO_BOOTMEM
arch/sparc/Kconfig:     select NO_BOOTMEM
arch/x86/Kconfig:config NO_BOOTMEM


so may need to
1. make 32bit ARM to use NO_BOOTMEM at first.

2 .we can add alloc_memblock as MACRO or inline for bootmem arches,

3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c

4. replace alloc_bootmem calling with alloc_memblock calling in core code.

Thanks

Yinghai

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Yinghai Lu]

On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>> >> On these SoCs which Santosh is working on, the main physical memory
>> >> mapping is above 4GB, with just a small alias below 4GB to allow the
>> >> system to boot without the MMU being on, as they may have more than
>> >> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>> >> suitable for use as a "lowmem" mapping.
>>
>> is that 32bit ARM or 64bit ARM?
>
> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.

32bit ARM does not support NO_BOOTMEM yet.

arch/arc/Kconfig:       select NO_BOOTMEM
arch/arm64/Kconfig:     select NO_BOOTMEM
arch/sparc/Kconfig:     select NO_BOOTMEM
arch/x86/Kconfig:config NO_BOOTMEM


so may need to
1. make 32bit ARM to use NO_BOOTMEM at first.

2 .we can add alloc_memblock as MACRO or inline for bootmem arches,

3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c

4. replace alloc_bootmem calling with alloc_memblock calling in core code.

Thanks

Yinghai

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote:
> On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>>>>> On these SoCs which Santosh is working on, the main physical memory
>>>>> mapping is above 4GB, with just a small alias below 4GB to allow the
>>>>> system to boot without the MMU being on, as they may have more than
>>>>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>>>>> suitable for use as a "lowmem" mapping.
>>>
>>> is that 32bit ARM or 64bit ARM?
>>
>> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.
> 
Thanks Russell for clarifying the issue on the thread. Another major
reason of not being to use 32 bit alias address space for lowmem
is that address space isn't coherent on the SOC am dealing with.

> 32bit ARM does not support NO_BOOTMEM yet.
> 
> arch/arc/Kconfig:       select NO_BOOTMEM
> arch/arm64/Kconfig:     select NO_BOOTMEM
> arch/sparc/Kconfig:     select NO_BOOTMEM
> arch/x86/Kconfig:config NO_BOOTMEM
> 
> 
> so may need to
> 1. make 32bit ARM to use NO_BOOTMEM at first.
> 
Sorry. I should have mentioned that in the change-log. 
I have been carrying some WIP patches for ARM. Will post them
on ARM list after finishing remainder of the testing.

> 2 .we can add alloc_memblock as MACRO or inline for bootmem arches,
> 
> 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c
> 
> 4. replace alloc_bootmem calling with alloc_memblock calling in core code.
> 
Great that we all agree to see back of nobootmem.c and have a direct
memblock API. Will be happy to help in conversion to proposed new interfaces
if I can get the alloc_memblock API and core related changes.

Will be good to know who is going to create proposed memblock API
so that we all can collaborate in conversion.

Regards,
Santosh 

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

Tejun,

On Monday 01 July 2013 10:10 AM, Santosh Shilimkar wrote:
> On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote:
>> On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>>>>>> On these SoCs which Santosh is working on, the main physical memory
>>>>>> mapping is above 4GB, with just a small alias below 4GB to allow the
>>>>>> system to boot without the MMU being on, as they may have more than
>>>>>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>>>>>> suitable for use as a "lowmem" mapping.
>>>>
>>>> is that 32bit ARM or 64bit ARM?
>>>
>>> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.
>>
> Thanks Russell for clarifying the issue on the thread. Another major
> reason of not being to use 32 bit alias address space for lowmem
> is that address space isn't coherent on the SOC am dealing with.
> 
>> 32bit ARM does not support NO_BOOTMEM yet.
>>
>> arch/arc/Kconfig:       select NO_BOOTMEM
>> arch/arm64/Kconfig:     select NO_BOOTMEM
>> arch/sparc/Kconfig:     select NO_BOOTMEM
>> arch/x86/Kconfig:config NO_BOOTMEM
>>
>>
>> so may need to
>> 1. make 32bit ARM to use NO_BOOTMEM at first.
>>
> Sorry. I should have mentioned that in the change-log. 
> I have been carrying some WIP patches for ARM. Will post them
> on ARM list after finishing remainder of the testing.
> 
>> 2 .we can add alloc_memblock as MACRO or inline for bootmem arches,
>>
>> 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c
>>
>> 4. replace alloc_bootmem calling with alloc_memblock calling in core code.
>>
> Great that we all agree to see back of nobootmem.c and have a direct
> memblock API. Will be happy to help in conversion to proposed new interfaces
> if I can get the alloc_memblock API and core related changes.
> 
> Will be good to know who is going to create proposed memblock API
> so that we all can collaborate in conversion.
> 
Any comments here. I would like to know your plan for the new
API. You might have seen on the ARM no-bootmem thread, we started to
move ARM to nobootmem with Russell's help.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

Tejun,

On Monday 01 July 2013 10:10 AM, Santosh Shilimkar wrote:
> On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote:
>> On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>>>>>> On these SoCs which Santosh is working on, the main physical memory
>>>>>> mapping is above 4GB, with just a small alias below 4GB to allow the
>>>>>> system to boot without the MMU being on, as they may have more than
>>>>>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>>>>>> suitable for use as a "lowmem" mapping.
>>>>
>>>> is that 32bit ARM or 64bit ARM?
>>>
>>> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.
>>
> Thanks Russell for clarifying the issue on the thread. Another major
> reason of not being to use 32 bit alias address space for lowmem
> is that address space isn't coherent on the SOC am dealing with.
> 
>> 32bit ARM does not support NO_BOOTMEM yet.
>>
>> arch/arc/Kconfig:       select NO_BOOTMEM
>> arch/arm64/Kconfig:     select NO_BOOTMEM
>> arch/sparc/Kconfig:     select NO_BOOTMEM
>> arch/x86/Kconfig:config NO_BOOTMEM
>>
>>
>> so may need to
>> 1. make 32bit ARM to use NO_BOOTMEM at first.
>>
> Sorry. I should have mentioned that in the change-log. 
> I have been carrying some WIP patches for ARM. Will post them
> on ARM list after finishing remainder of the testing.
> 
>> 2 .we can add alloc_memblock as MACRO or inline for bootmem arches,
>>
>> 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c
>>
>> 4. replace alloc_bootmem calling with alloc_memblock calling in core code.
>>
> Great that we all agree to see back of nobootmem.c and have a direct
> memblock API. Will be happy to help in conversion to proposed new interfaces
> if I can get the alloc_memblock API and core related changes.
> 
> Will be good to know who is going to create proposed memblock API
> so that we all can collaborate in conversion.
> 
Any comments here. I would like to know your plan for the new
API. You might have seen on the ARM no-bootmem thread, we started to
move ARM to nobootmem with Russell's help.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Thu, Jul 25, 2013 at 06:33:14PM -0400, Santosh Shilimkar wrote:
> Any comments here. I would like to know your plan for the new
> API. You might have seen on the ARM no-bootmem thread, we started to
> move ARM to nobootmem with Russell's help.

Ooh, the plan sounds good to me and I was thinking you were gonna do
it?

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Thu, Jul 25, 2013 at 06:33:14PM -0400, Santosh Shilimkar wrote:
> Any comments here. I would like to know your plan for the new
> API. You might have seen on the ARM no-bootmem thread, we started to
> move ARM to nobootmem with Russell's help.

Ooh, the plan sounds good to me and I was thinking you were gonna do
it?

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Thursday 25 July 2013 06:36 PM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jul 25, 2013 at 06:33:14PM -0400, Santosh Shilimkar wrote:
>> Any comments here. I would like to know your plan for the new
>> API. You might have seen on the ARM no-bootmem thread, we started to
>> move ARM to nobootmem with Russell's help.
> 
> Ooh, the plan sounds good to me and I was thinking you were gonna do
> it?
> 
Wooo..

Sorry if I wasn't clear before, but I need help to at least have new
memblock API support since I am not familiar with memblock code. 
I could help in adaptation to the new API for ARM arch and
core kernel code.

Let me know your thoughts.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Thursday 25 July 2013 06:36 PM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jul 25, 2013 at 06:33:14PM -0400, Santosh Shilimkar wrote:
>> Any comments here. I would like to know your plan for the new
>> API. You might have seen on the ARM no-bootmem thread, we started to
>> move ARM to nobootmem with Russell's help.
> 
> Ooh, the plan sounds good to me and I was thinking you were gonna do
> it?
> 
Wooo..

Sorry if I wasn't clear before, but I need help to at least have new
memblock API support since I am not familiar with memblock code. 
I could help in adaptation to the new API for ARM arch and
core kernel code.

Let me know your thoughts.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Thu, Jul 25, 2013 at 07:15:11PM -0400, Santosh Shilimkar wrote:
> Sorry if I wasn't clear before, but I need help to at least have new
> memblock API support since I am not familiar with memblock code. 
> I could help in adaptation to the new API for ARM arch and
> core kernel code.
> 
> Let me know your thoughts.

Unfortunately, I'm currently a bit too occupied to work on it myself.
Any volunteers?

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

Tejun,

On Thursday 25 July 2013 11:08 PM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jul 25, 2013 at 07:15:11PM -0400, Santosh Shilimkar wrote:
>> Sorry if I wasn't clear before, but I need help to at least have new
>> memblock API support since I am not familiar with memblock code. 
>> I could help in adaptation to the new API for ARM arch and
>> core kernel code.
>>
>> Let me know your thoughts.
> 
> Unfortunately, I'm currently a bit too occupied to work on it myself.
> Any volunteers?
> 
Looking at the situation, how about proceeding with patch updating
the bootmem API signatures to use phys_addr_t  which can unblock me
to get my machine working.

Introduction of new API, conversions of core kernel code and then
arches moving away from bootmem is going to take significant time
anyways. I will continue my effort to get ARM port moved to no-bootmem
and get that merged.

Let me know how to make progress here. Appreciate your help on the subject.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

Tejun,

On Thursday 25 July 2013 11:08 PM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jul 25, 2013 at 07:15:11PM -0400, Santosh Shilimkar wrote:
>> Sorry if I wasn't clear before, but I need help to at least have new
>> memblock API support since I am not familiar with memblock code. 
>> I could help in adaptation to the new API for ARM arch and
>> core kernel code.
>>
>> Let me know your thoughts.
> 
> Unfortunately, I'm currently a bit too occupied to work on it myself.
> Any volunteers?
> 
Looking at the situation, how about proceeding with patch updating
the bootmem API signatures to use phys_addr_t  which can unblock me
to get my machine working.

Introduction of new API, conversions of core kernel code and then
arches moving away from bootmem is going to take significant time
anyways. I will continue my effort to get ARM port moved to no-bootmem
and get that merged.

Let me know how to make progress here. Appreciate your help on the subject.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Fri, Aug 02, 2013 at 05:06:02PM -0400, Santosh Shilimkar wrote:
> Looking at the situation, how about proceeding with patch updating
> the bootmem API signatures to use phys_addr_t  which can unblock me
> to get my machine working.

I'm not sure about that.  No matter how you play it, it'll end up
duplicating memblock interface.

> Introduction of new API, conversions of core kernel code and then

What new API are we talking about?  Wasn't the plan to convert core
kernel code to use memblock and let bootmem emulate bootmem API?
There's no new API.

> arches moving away from bootmem is going to take significant time

And arches moving away from bootmem doesn't have to happen now.

> anyways. I will continue my effort to get ARM port moved to no-bootmem
> and get that merged.

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Monday 05 August 2013 11:01 AM, Tejun Heo wrote:
> Hello,
> 
> On Fri, Aug 02, 2013 at 05:06:02PM -0400, Santosh Shilimkar wrote:
>> Looking at the situation, how about proceeding with patch updating
>> the bootmem API signatures to use phys_addr_t  which can unblock me
>> to get my machine working.
> 
> I'm not sure about that.  No matter how you play it, it'll end up
> duplicating memblock interface.
> 
fair enough.

>> Introduction of new API, conversions of core kernel code and then
> 
> What new API are we talking about?  Wasn't the plan to convert core
> kernel code to use memblock and let bootmem emulate bootmem API?
> There's no new API.
> 
So looks like I am bit confused here. The current memblock_alloc()
API just returns the physical address which not mapped memory.
Most of the bootmem users including core code expects the
mapped memory pointer which the code can directly operate on.
So the current memblock_alloc() isn't going to help. The nobootmem.c
has __alloc_memory_core_early() which is actually used by most of
the bootmem wrappers to achieve the same. So my assumption was
that we need an equivalent exported memblock API.

What am I missing?

>> arches moving away from bootmem is going to take significant time
> 
> And arches moving away from bootmem doesn't have to happen now.
> 
I agree. The core code conversion is more of an issue.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Monday 05 August 2013 11:01 AM, Tejun Heo wrote:
> Hello,
> 
> On Fri, Aug 02, 2013 at 05:06:02PM -0400, Santosh Shilimkar wrote:
>> Looking at the situation, how about proceeding with patch updating
>> the bootmem API signatures to use phys_addr_t  which can unblock me
>> to get my machine working.
> 
> I'm not sure about that.  No matter how you play it, it'll end up
> duplicating memblock interface.
> 
fair enough.

>> Introduction of new API, conversions of core kernel code and then
> 
> What new API are we talking about?  Wasn't the plan to convert core
> kernel code to use memblock and let bootmem emulate bootmem API?
> There's no new API.
> 
So looks like I am bit confused here. The current memblock_alloc()
API just returns the physical address which not mapped memory.
Most of the bootmem users including core code expects the
mapped memory pointer which the code can directly operate on.
So the current memblock_alloc() isn't going to help. The nobootmem.c
has __alloc_memory_core_early() which is actually used by most of
the bootmem wrappers to achieve the same. So my assumption was
that we need an equivalent exported memblock API.

What am I missing?

>> arches moving away from bootmem is going to take significant time
> 
> And arches moving away from bootmem doesn't have to happen now.
> 
I agree. The core code conversion is more of an issue.

Regards,
Santosh

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Tejun Heo]

Hello,

On Mon, Aug 05, 2013 at 11:29:46AM -0400, Santosh Shilimkar wrote:
> So looks like I am bit confused here. The current memblock_alloc()
> API just returns the physical address which not mapped memory.

The memory returned by memblock is mapped if the memory area being
allocated can be mappable.  To access, the address just needs to be
converted to va.

> Most of the bootmem users including core code expects the
> mapped memory pointer which the code can directly operate on.
> So the current memblock_alloc() isn't going to help. The nobootmem.c
> has __alloc_memory_core_early() which is actually used by most of
> the bootmem wrappers to achieve the same. So my assumption was
> that we need an equivalent exported memblock API.
> 
> What am I missing?

Oh, you weren't.  I was.  I thought we already had full interface
implemented.  Yeah, it looks like we need to build something new
around memblock / __alloc_memory_core_early().

Thanks.

-- 
tejun

Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM

[Santosh Shilimkar]

On Monday 05 August 2013 11:38 AM, Tejun Heo wrote:
> Hello,
> 
> On Mon, Aug 05, 2013 at 11:29:46AM -0400, Santosh Shilimkar wrote:
>> So looks like I am bit confused here. The current memblock_alloc()
>> API just returns the physical address which not mapped memory.
> 
> The memory returned by memblock is mapped if the memory area being
> allocated can be mappable.  To access, the address just needs to be
> converted to va.
> 
>> Most of the bootmem users including core code expects the
>> mapped memory pointer which the code can directly operate on.
>> So the current memblock_alloc() isn't going to help. The nobootmem.c
>> has __alloc_memory_core_early() which is actually used by most of
>> the bootmem wrappers to achieve the same. So my assumption was
>> that we need an equivalent exported memblock API.
>>
>> What am I missing?
> 
> Oh, you weren't.  I was.  I thought we already had full interface
> implemented.  Yeah, it looks like we need to build something new
> around memblock / __alloc_memory_core_early().
> 
Exactly. This is what actually I referred as the new API.

Regards,
Santosh