Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1646689 > unrolled thread

Re: [PATCH 00/21] MIPS memblock: Remove bootmem code and switch to NO_BOOTMEM

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 00/21] MIPS memblock: Remove bootmem code and switch to  NO_BOOTMEM Marcin Nowakowski <marcin.nowakowski@imgtec.com> - 2017-05-22 12:00 +0200
    Re: [PATCH 00/21] MIPS memblock: Remove bootmem code and switch to  NO_BOOTMEM Serge Semin <fancer.lancer@gmail.com> - 2017-05-22 12:30 +0200
      Re: [PATCH 00/21] MIPS memblock: Remove bootmem code and switch to  NO_BOOTMEM Marcin Nowakowski <marcin.nowakowski@imgtec.com> - 2017-05-22 14:20 +0200
      Re: [PATCH 00/21] MIPS memblock: Remove bootmem code and switch to  NO_BOOTMEM Joshua Kinard <kumba@gentoo.org> - 2017-05-22 15:00 +0200
        Re: [PATCH 00/21] MIPS memblock: Remove bootmem code and switch to  NO_BOOTMEM Serge Semin <fancer.lancer@gmail.com> - 2017-05-22 15:10 +0200
          Re: [PATCH 00/21] MIPS memblock: Remove bootmem code and switch to  NO_BOOTMEM Serge Semin <fancer.lancer@gmail.com> - 2017-05-22 15:30 +0200

#1646689 — Re: [PATCH 00/21] MIPS memblock: Remove bootmem code and switch to NO_BOOTMEM

Hi Serge,

On 19.12.2016 03:07, Serge Semin wrote:
> Most of the modern platforms supported by linux kernel have already
> been cleaned up of old bootmem allocator by moving to nobootmem
> interface wrapping up the memblock. This patchset is the first
> attempt to do the similar improvement for MIPS for UMA systems
> only.
>
> Even though the porting was performed as much careful as possible
> there still might be problem with support of some platforms,
> especially Loonson3 or SGI IP27, which perform early memory manager
> initialization by their self.
>
> The patchset is split so individual patch being consistent in
> functional and buildable ways. But the MIPS early memory manager
> will work correctly only either with or without the whole set being
> applied. For the same reason a reviewer should not pay much attention
> to methods bootmem_init(), arch_mem_init(), paging_init() and
> mem_init() until they are fully refactored.
>
> The patchset is applied on top of kernel v4.9.

Have you progressed any further with these patches?
They would definitely be useful to include for MIPS arch, so can you let 
us know if you are planning to send any updated version?

thanks,
Marcin

[toc] | [next] | [standalone]

#1646708

On Mon, May 22, 2017 at 11:48:36AM +0200, Marcin Nowakowski <marcin.nowakowski@imgtec.com> wrote:

Hello Marcin,

> Hi Serge,
> 
> On 19.12.2016 03:07, Serge Semin wrote:
> >Most of the modern platforms supported by linux kernel have already
> >been cleaned up of old bootmem allocator by moving to nobootmem
> >interface wrapping up the memblock. This patchset is the first
> >attempt to do the similar improvement for MIPS for UMA systems
> >only.
> >
> >Even though the porting was performed as much careful as possible
> >there still might be problem with support of some platforms,
> >especially Loonson3 or SGI IP27, which perform early memory manager
> >initialization by their self.
> >
> >The patchset is split so individual patch being consistent in
> >functional and buildable ways. But the MIPS early memory manager
> >will work correctly only either with or without the whole set being
> >applied. For the same reason a reviewer should not pay much attention
> >to methods bootmem_init(), arch_mem_init(), paging_init() and
> >mem_init() until they are fully refactored.
> >
> >The patchset is applied on top of kernel v4.9.
> 
> Have you progressed any further with these patches?
> They would definitely be useful to include for MIPS arch, so can you let us
> know if you are planning to send any updated version?
> 
> thanks,
> Marcin

Sorry for such a long delay with response. I have been really busy
during last three months. Alas I'll still be busy for next 1-2
months as well. You know how it usually works with urgent projects.
One needs to do this thing, then that thing, and at some point I just
forgot about this thread.

Regarding the patchset. I'm still pretty much eager to make it being
part of kernel MIPS arch. But there was a problem I outlined
in the patchset header message, which I can't fix by myself.
Particulary It's connected with Loonson3 or SGI IP27 code alteration,
so to make it free of ancient boot_mem_map dependencies (see the
patchset header message). Without a help from someone, who has
Loonson64 and SGI IP27 hardware and strong desire to make it free of
old bootmem allocator, it is useless to make any progress from my
side. That's why Ralf moved this email-thread into RFC actually.
Anyway If either you or someone else has got such hardware and is
interested in the cooperation, I'll be more than happy to push
my efforts forward with this patchset contribution. But only after
I got a bit less busy with my work. As I said it will happen within
next 1-2 months. So do you have the hardware and desire to be part
of this?

Regards,
-Sergey

[toc] | [prev] | [next] | [standalone]

#1646814

Hi Serge,

On 22.05.2017 12:26, Serge Semin wrote:

> Regarding the patchset. I'm still pretty much eager to make it being
> part of kernel MIPS arch. But there was a problem I outlined
> in the patchset header message, which I can't fix by myself.
> Particulary It's connected with Loonson3 or SGI IP27 code alteration,
> so to make it free of ancient boot_mem_map dependencies (see the
> patchset header message). Without a help from someone, who has
> Loonson64 and SGI IP27 hardware and strong desire to make it free of
> old bootmem allocator, it is useless to make any progress from my
> side. That's why Ralf moved this email-thread into RFC actually.
> Anyway If either you or someone else has got such hardware and is
> interested in the cooperation, I'll be more than happy to push
> my efforts forward with this patchset contribution. But only after
> I got a bit less busy with my work. As I said it will happen within
> next 1-2 months. So do you have the hardware and desire to be part
> of this?

I should be able to update/test the changes on a Loongson64 platform.


Marcin

[toc] | [prev] | [next] | [standalone]

#1646855

On 05/22/2017 06:26, Serge Semin wrote:
> On Mon, May 22, 2017 at 11:48:36AM +0200, Marcin Nowakowski <marcin.nowakowski@imgtec.com> wrote:
> 
> Hello Marcin,
> 
>> Hi Serge,
>>
>> On 19.12.2016 03:07, Serge Semin wrote:
>>> Most of the modern platforms supported by linux kernel have already
>>> been cleaned up of old bootmem allocator by moving to nobootmem
>>> interface wrapping up the memblock. This patchset is the first
>>> attempt to do the similar improvement for MIPS for UMA systems
>>> only.
>>>
>>> Even though the porting was performed as much careful as possible
>>> there still might be problem with support of some platforms,
>>> especially Loonson3 or SGI IP27, which perform early memory manager
>>> initialization by their self.
>>>
>>> The patchset is split so individual patch being consistent in
>>> functional and buildable ways. But the MIPS early memory manager
>>> will work correctly only either with or without the whole set being
>>> applied. For the same reason a reviewer should not pay much attention
>>> to methods bootmem_init(), arch_mem_init(), paging_init() and
>>> mem_init() until they are fully refactored.
>>>
>>> The patchset is applied on top of kernel v4.9.
>>
>> Have you progressed any further with these patches?
>> They would definitely be useful to include for MIPS arch, so can you let us
>> know if you are planning to send any updated version?
>>
>> thanks,
>> Marcin
> 
> Sorry for such a long delay with response. I have been really busy
> during last three months. Alas I'll still be busy for next 1-2
> months as well. You know how it usually works with urgent projects.
> One needs to do this thing, then that thing, and at some point I just
> forgot about this thread.
> 
> Regarding the patchset. I'm still pretty much eager to make it being
> part of kernel MIPS arch. But there was a problem I outlined
> in the patchset header message, which I can't fix by myself.
> Particulary It's connected with Loonson3 or SGI IP27 code alteration,
> so to make it free of ancient boot_mem_map dependencies (see the
> patchset header message). Without a help from someone, who has
> Loonson64 and SGI IP27 hardware and strong desire to make it free of
> old bootmem allocator, it is useless to make any progress from my
> side. That's why Ralf moved this email-thread into RFC actually.
> Anyway If either you or someone else has got such hardware and is
> interested in the cooperation, I'll be more than happy to push
> my efforts forward with this patchset contribution. But only after
> I got a bit less busy with my work. As I said it will happen within
> next 1-2 months. So do you have the hardware and desire to be part
> of this?
> 
> Regards,
> -Sergey

I have an SGI Onyx2 and just recently acquired a working SGI Origin 200.  The
Onyx2 has NUMA issues yet to be hunted down, but I got ~3 days uptime out of
the Origin 200 running compiles before powering it down.  Mainline needs 2-3
small patches to make IP27 workable, last I tested.

I'd have to look at the IP27 code again and see if I can make sense of what
it's doing.  I think it dealt with either setting up memory for an initrd
(which I haven't used in over a decade), or it's for the NUMA stuff to discover
all memory on each node.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

[toc] | [prev] | [next] | [standalone]

#1646871

Hello folks,

On Mon, May 22, 2017 at 08:47:20AM -0400, Joshua Kinard <kumba@gentoo.org> wrote:
> On 05/22/2017 06:26, Serge Semin wrote:
> > On Mon, May 22, 2017 at 11:48:36AM +0200, Marcin Nowakowski <marcin.nowakowski@imgtec.com> wrote:
> > 
> > Hello Marcin,
> > 
> >> Hi Serge,
> >>
> >> On 19.12.2016 03:07, Serge Semin wrote:
> >>> Most of the modern platforms supported by linux kernel have already
> >>> been cleaned up of old bootmem allocator by moving to nobootmem
> >>> interface wrapping up the memblock. This patchset is the first
> >>> attempt to do the similar improvement for MIPS for UMA systems
> >>> only.
> >>>
> >>> Even though the porting was performed as much careful as possible
> >>> there still might be problem with support of some platforms,
> >>> especially Loonson3 or SGI IP27, which perform early memory manager
> >>> initialization by their self.
> >>>
> >>> The patchset is split so individual patch being consistent in
> >>> functional and buildable ways. But the MIPS early memory manager
> >>> will work correctly only either with or without the whole set being
> >>> applied. For the same reason a reviewer should not pay much attention
> >>> to methods bootmem_init(), arch_mem_init(), paging_init() and
> >>> mem_init() until they are fully refactored.
> >>>
> >>> The patchset is applied on top of kernel v4.9.
> >>
> >> Have you progressed any further with these patches?
> >> They would definitely be useful to include for MIPS arch, so can you let us
> >> know if you are planning to send any updated version?
> >>
> >> thanks,
> >> Marcin
> > 
> > Sorry for such a long delay with response. I have been really busy
> > during last three months. Alas I'll still be busy for next 1-2
> > months as well. You know how it usually works with urgent projects.
> > One needs to do this thing, then that thing, and at some point I just
> > forgot about this thread.
> > 
> > Regarding the patchset. I'm still pretty much eager to make it being
> > part of kernel MIPS arch. But there was a problem I outlined
> > in the patchset header message, which I can't fix by myself.
> > Particulary It's connected with Loonson3 or SGI IP27 code alteration,
> > so to make it free of ancient boot_mem_map dependencies (see the
> > patchset header message). Without a help from someone, who has
> > Loonson64 and SGI IP27 hardware and strong desire to make it free of
> > old bootmem allocator, it is useless to make any progress from my
> > side. That's why Ralf moved this email-thread into RFC actually.
> > Anyway If either you or someone else has got such hardware and is
> > interested in the cooperation, I'll be more than happy to push
> > my efforts forward with this patchset contribution. But only after
> > I got a bit less busy with my work. As I said it will happen within
> > next 1-2 months. So do you have the hardware and desire to be part
> > of this?
> > 
> > Regards,
> > -Sergey
> 
> I have an SGI Onyx2 and just recently acquired a working SGI Origin 200.  The
> Onyx2 has NUMA issues yet to be hunted down, but I got ~3 days uptime out of
> the Origin 200 running compiles before powering it down.  Mainline needs 2-3
> small patches to make IP27 workable, last I tested.
> 
> I'd have to look at the IP27 code again and see if I can make sense of what
> it's doing.  I think it dealt with either setting up memory for an initrd
> (which I haven't used in over a decade), or it's for the NUMA stuff to discover
> all memory on each node.
> 
> -- 
> Joshua Kinard
> Gentoo/MIPS
> kumba@gentoo.org
> 6144R/F5C6C943 2015-04-27
> 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
> 
> "The past tempts us, the present confuses us, the future frightens us.  And our
> lives slip away, moment by moment, lost in that vast, terrible in-between."
> 
> --Emperor Turhan, Centauri Republic

It's great to hear of your willingness to help. Since both Loonson64 and SGI IP27
problematic architecture-specific code will be appropriately altered, I'll publish
the fixed general MIPS-memblock patchset within two months. I'll also try to
involve Ralf in it when I'm ready, so to make sure all my alterations are made
within kernel arch-code coding style. While I'm working on it, you can still use
the current patchset for some limited tests.

Regards,
-Sergey

[toc] | [prev] | [next] | [standalone]

#1646888

Hello Alexandr,
Ok, I will.

Regards,
-Sergey

On Mon, May 22, 2017 at 03:20:44PM +0200, Alexander Sverdlin <alexander.sverdlin@nokia.com> wrote:
> Hello Serge,
> 
> On 22/05/17 15:03, Serge Semin wrote:
> >> I have an SGI Onyx2 and just recently acquired a working SGI Origin 200.  The
> >> Onyx2 has NUMA issues yet to be hunted down, but I got ~3 days uptime out of
> >> the Origin 200 running compiles before powering it down.  Mainline needs 2-3
> >> small patches to make IP27 workable, last I tested.
> >>
> >> I'd have to look at the IP27 code again and see if I can make sense of what
> >> it's doing.  I think it dealt with either setting up memory for an initrd
> >> (which I haven't used in over a decade), or it's for the NUMA stuff to discover
> >> all memory on each node.
> >>
> >> -- 
> >> Joshua Kinard
> >> Gentoo/MIPS
> >> kumba@gentoo.org
> >> 6144R/F5C6C943 2015-04-27
> >> 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
> >>
> >> "The past tempts us, the present confuses us, the future frightens us.  And our
> >> lives slip away, moment by moment, lost in that vast, terrible in-between."
> >>
> >> --Emperor Turhan, Centauri Republic
> > It's great to hear of your willingness to help. Since both Loonson64 and SGI IP27
> > problematic architecture-specific code will be appropriately altered, I'll publish
> > the fixed general MIPS-memblock patchset within two months. I'll also try to
> > involve Ralf in it when I'm ready, so to make sure all my alterations are made
> > within kernel arch-code coding style. While I'm working on it, you can still use
> > the current patchset for some limited tests.
> 
> Please Cc me in this case, I should be able to test on Octeon MIPS64 platform.
> 
> -- 
> Best regards,
> Alexander Sverdlin.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web