Hello folks, On Mon, May 22, 2017 at 08:47:20AM -0400, Joshua Kinard <kumba@xxxxxxxxxx> wrote: > On 05/22/2017 06:26, Serge Semin wrote: > > On Mon, May 22, 2017 at 11:48:36AM +0200, Marcin Nowakowski <marcin.nowakowski@xxxxxxxxxx> 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@xxxxxxxxxx > 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
