4 ms·

Is this really such a big issue? Currently there are already multiple arm builds from some distros to deal with similar problems: https://archlinuxarm.org/about

Is this really such a big issue? Currently there are already multiple arm builds from some distros to deal with similar problems: https://archlinuxarm.org/about/downloads https://archlinuxarm.org/about/downloads

rwmj 8y ago
It's exactly the fragmentation of ARM that I'd like to avoid. Same story goes for bootloaders, kernels, out-of-tree drivers etc. You might find my 15 minute talk at the RISC-V workshop interesting on this subject: https://rwmj.wordpress.com/2018/05/21/my-talk-from-the-risc-v-workshop-in-barcelona/ https://rwmj.wordpress.com/2018/05/21/my-talk-from-the-risc-... The bit about RISC-V on servers starts around 5 mins in.
- ailideex 8y ago
  If the only issue is the kernel (which I don't know it is) ... I'm not that sure there is such a big problem. If it is essentially different architectures which requires all binaries to be compiled differently then the problem is much more dire. I think your points in the video is important - or rather, should be important - but from the fragmentation of ARM it seems they are not as important to chip makers as they should be. However ARM's fragmentation seems to have not been a serious impediment to it's adoption. I think though going forward the solution may be to target higher level machines (i.e. JVM). This obviously is not realistic for the kernel - but for software that most people want to run on RHEL it would most likely be fine.
  - rwmj 8y ago
    For RVC the problem is everywhere. However I argue in the video that even just different kernels, bootloaders or out-of-tree drivers are a real problem when you're deploying servers at scale. ARM has distinctly not been popular in the data center (despite years of work). That's for many reasons but one is surely the fragmentation of the platform.
    - wolfgke 8y ago
      > ARM has distinctly not been popular in the data center (despite years of work). That's for many reasons but one is surely the fragmentation of the platform. At least for the server realm, ARM defined the "Server Base System Architecture" standard > https://en.wikipedia.org/w/index.php?title=Server_Base_System_Architecture&oldid=785711251 https://en.wikipedia.org/w/index.php?title=Server_Base_Syste... exactly to avoid fragmentation in an area where custumers desire standardization.
- yazr 8y ago
  Fascinating talk. Feels like every line has been earned with tears and sweat ;) Can i ask off-topic about the build farm you mention (approx 12:00). Is build performance an issue ? How long do typical builds take ? Would a x5 performance improvement become a must-have feature ?
  - rwmj 8y ago
    Actually the current build farm with 3 x HiFive Unleashed boards and a bunch of VMs is fine (perhaps less so if we had to build everything twice). There are two bottlenecks now: lack of SATA disks on two of the boards, instead we're using NBD; and the Koji build software itself which introduces a lot of overhead by creating from scratch fresh buildroots for every build.
    - ailideex 8y ago
      Is there a reason why you are not cross compiling?
- phkahler 8y ago
  >> It's exactly the fragmentation of ARM that I'd like to avoid. RISC-V has an extensible ISA so it's likely to be a mess by design. I'm huge fan of risc-v so I really feel bad saying this. It's telling that RV-IMAFDC is the base for unix systems. It was originally IMAFD = G, but now GC is the standard. Then there's the V extension which I think will be very important and it already sounds like it may be fragmented (graphics and AI may be extra beyond vectors). But then there is space in the instruction encodings explicitly for custom extensions. These variations are important, and the ability to customize in a standard way is too. I think it's going to be an amazing decade or two in the CPU space because of risc-v but it's also going to be a lot of churn IMHO. Once open designs catch up to the state of the art and a real base ISA solidifies I hope a RISC-6 comes along with a more optimal encoding and things become really stable for a long time. But that's just my optimism getting out of hand.
  - nickik 8y ago
    Why do you talk about 'the real base ISA' solidifies? The 'real base ISA' is solidified and its designed to let you run a lot of software at minimal complexity. The problem is that there is NEVER one optimal ISA for all applications. It makes absolutely no sense to have V, T, J extensions in the new 'real base' because there are tons of systems that don't ever need it and it would be a waste. That's why the RISC-V foundation defines profiles for certain application domains. RV64GC is the logic one for Linux for the moment. Also you ignore that very often an ISA is not used as a mass market product, but rather in a smaller more specialized space. The costume extensions are very important for people like that. In other cases, the potential AI extensions for vector for example, will probably never gone show up in standard profile for Linux. I think what we are like gone see is that RV64GC will remain the base level for the Linux profile and eventually more advanced profile with V and potentially others will emerge. The whole point is that no long build everything around ISAs that is never optimal but rather around profiles.
    - phkahler 8y ago
      >> Why do you talk about 'the real base ISA' solidifies? The 'real base ISA' is solidified and its designed to let you run a lot of software at minimal complexity. The "real base ISA" will be whatever set of options becomes widespread 10-15 years from now. In my mind it's entirely feasible (though not as likely) that the approach of using hundreds of minion cores (see Esperanto) to do graphics will become a common thing (since there is no free GPU and none around the corner). If that is the case, the V extension will become part of the "real base ISA" because everyone will want it. So far the A and C extension went from optional to necessary - it would be naive to think it will stop there. Also, as implementations improve someone may come up with a low cost (low area) way to implement DSP instructions. Maybe that becomes common because the low additional cost is a "why not?". That's part of my point too, the flexibility will bring innovation and that may lead to certain things naturally becoming part of most peoples expectations. It looks like OpenGL has done something similar. They had a few specifications (ES in particular) for different classes of hardware, but as it became clear that certain features could be handled by the lesser hardware variants those became part of the standard.
hsivonen 8y ago
32-bit ARM also having a problem doesn't mean it's not a problem.
IshKebab 8y ago
You link shows exactly how big an issue this is.

rwmj 8y ago

It's exactly the fragmentation of ARM that I'd like to avoid. Same story goes for bootloaders, kernels, out-of-tree drivers etc. You might find my 15 minute talk at the RISC-V workshop interesting on this subject: https://rwmj.wordpress.com/2018/05/21/my-talk-from-the-risc-v-workshop-in-barcelona/ https://rwmj.wordpress.com/2018/05/21/my-talk-from-the-risc-... The bit about RISC-V on servers starts around 5 mins in.

ailideex 8y ago
If the only issue is the kernel (which I don't know it is) ... I'm not that sure there is such a big problem. If it is essentially different architectures which requires all binaries to be compiled differently then the problem is much more dire. I think your points in the video is important - or rather, should be important - but from the fragmentation of ARM it seems they are not as important to chip makers as they should be. However ARM's fragmentation seems to have not been a serious impediment to it's adoption. I think though going forward the solution may be to target higher level machines (i.e. JVM). This obviously is not realistic for the kernel - but for software that most people want to run on RHEL it would most likely be fine.
- rwmj 8y ago
  For RVC the problem is everywhere. However I argue in the video that even just different kernels, bootloaders or out-of-tree drivers are a real problem when you're deploying servers at scale. ARM has distinctly not been popular in the data center (despite years of work). That's for many reasons but one is surely the fragmentation of the platform.
  - wolfgke 8y ago
    > ARM has distinctly not been popular in the data center (despite years of work). That's for many reasons but one is surely the fragmentation of the platform. At least for the server realm, ARM defined the "Server Base System Architecture" standard > https://en.wikipedia.org/w/index.php?title=Server_Base_System_Architecture&oldid=785711251 https://en.wikipedia.org/w/index.php?title=Server_Base_Syste... exactly to avoid fragmentation in an area where custumers desire standardization.
yazr 8y ago
Fascinating talk. Feels like every line has been earned with tears and sweat ;) Can i ask off-topic about the build farm you mention (approx 12:00). Is build performance an issue ? How long do typical builds take ? Would a x5 performance improvement become a must-have feature ?
- rwmj 8y ago
  Actually the current build farm with 3 x HiFive Unleashed boards and a bunch of VMs is fine (perhaps less so if we had to build everything twice). There are two bottlenecks now: lack of SATA disks on two of the boards, instead we're using NBD; and the Koji build software itself which introduces a lot of overhead by creating from scratch fresh buildroots for every build.
  - ailideex 8y ago
    Is there a reason why you are not cross compiling?
phkahler 8y ago
>> It's exactly the fragmentation of ARM that I'd like to avoid. RISC-V has an extensible ISA so it's likely to be a mess by design. I'm huge fan of risc-v so I really feel bad saying this. It's telling that RV-IMAFDC is the base for unix systems. It was originally IMAFD = G, but now GC is the standard. Then there's the V extension which I think will be very important and it already sounds like it may be fragmented (graphics and AI may be extra beyond vectors). But then there is space in the instruction encodings explicitly for custom extensions. These variations are important, and the ability to customize in a standard way is too. I think it's going to be an amazing decade or two in the CPU space because of risc-v but it's also going to be a lot of churn IMHO. Once open designs catch up to the state of the art and a real base ISA solidifies I hope a RISC-6 comes along with a more optimal encoding and things become really stable for a long time. But that's just my optimism getting out of hand.
- nickik 8y ago
  Why do you talk about 'the real base ISA' solidifies? The 'real base ISA' is solidified and its designed to let you run a lot of software at minimal complexity. The problem is that there is NEVER one optimal ISA for all applications. It makes absolutely no sense to have V, T, J extensions in the new 'real base' because there are tons of systems that don't ever need it and it would be a waste. That's why the RISC-V foundation defines profiles for certain application domains. RV64GC is the logic one for Linux for the moment. Also you ignore that very often an ISA is not used as a mass market product, but rather in a smaller more specialized space. The costume extensions are very important for people like that. In other cases, the potential AI extensions for vector for example, will probably never gone show up in standard profile for Linux. I think what we are like gone see is that RV64GC will remain the base level for the Linux profile and eventually more advanced profile with V and potentially others will emerge. The whole point is that no long build everything around ISAs that is never optimal but rather around profiles.
  - phkahler 8y ago
    >> Why do you talk about 'the real base ISA' solidifies? The 'real base ISA' is solidified and its designed to let you run a lot of software at minimal complexity. The "real base ISA" will be whatever set of options becomes widespread 10-15 years from now. In my mind it's entirely feasible (though not as likely) that the approach of using hundreds of minion cores (see Esperanto) to do graphics will become a common thing (since there is no free GPU and none around the corner). If that is the case, the V extension will become part of the "real base ISA" because everyone will want it. So far the A and C extension went from optional to necessary - it would be naive to think it will stop there. Also, as implementations improve someone may come up with a low cost (low area) way to implement DSP instructions. Maybe that becomes common because the low additional cost is a "why not?". That's part of my point too, the flexibility will bring innovation and that may lead to certain things naturally becoming part of most peoples expectations. It looks like OpenGL has done something similar. They had a few specifications (ES in particular) for different classes of hardware, but as it became clear that certain features could be handled by the lesser hardware variants those became part of the standard.

hsivonen 8y ago

32-bit ARM also having a problem doesn't mean it's not a problem.

IshKebab 8y ago

You link shows exactly how big an issue this is.