Announcement

Collapse
No announcement yet.

RHEL9 Likely To Drop Older x86_64 CPUs, Fedora Can Better Prepare With "Enterprise Linux Next"

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by CommunityMember View Post
    I don't think it has yet been decided on the specific feature requirements, but remember that RHEL is targeted towards supporting enterprise customers and solutions, which typically means DCs, and that means recent server class hardware (anyone who has actually done the TCO math for a DC can show that after a few generations of hardware it is cheaper to replace the hardware than keep it running), and not consumer devices. Sure, it is nice to be able to support someone's low end laptop, but RH makes their money from paying enterprises, which deploy serious iron, for the most part. How many people here can say they are actually paying full RH support prices for their laptops or seven year old servers? Those people can certainly make the case to RH that their loss of revenue may be important, but it is unlikely to be significant enough to change anyone's mind as to where to invest their resources (QA is extremely expensive for these enterprise vendors).
    What about people who use RHEL on their personal machines to be consistent with the "serious iron" they deal with at work?

    You know, the ones who would switch all the serious iron to SUSE or Ubuntu rather than "upgrade" their own laptop (see chithanh's comment)?

    Comment


    • #22
      Guys,
      By the time rhel9 becomes a thing, gcc will fully support "fat" binaries with multiple optimized versions of the same function and switching between them at runtime.
      So I see no issue whatsoever to build whole distros with binaries that include all possible optimizations, from generic to avx512 and everything inbetween.

      Comment


      • #23
        Originally posted by pegasus View Post
        By the time rhel9 becomes a thing, gcc will fully support "fat" binaries with multiple optimized versions of the same function and switching between them at runtime.
        Where can we follow the progress of this feature in gcc? Have patches been submitted for review?
        Last edited by Space Heater; 03-27-2020, 07:44 PM.

        Comment


        • #24
          Originally posted by zxy_thf View Post
          You need a newer kernel (cannot remember the exact version, but CentOS 7 doesn't have it and Ubuntu 18.04 has).

          uname -a
          Linux ubugrat 5.4.0-18-generic #22-Ubuntu SMP Sat Mar 7 18:13:06 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

          vendor_id : AuthenticAMD
          cpu family : 21
          model : 101
          model name : AMD PRO A12-9800B R7, 12 COMPUTE CORES 4C+8G
          stepping : 1
          microcode : 0x600611a
          cpu MHz : 1794.015
          cache size : 1024 KB
          physical idprocessor : 0
          siblings : 4
          core id : 3
          cpu cores : 2
          apicid : 19
          initial apicid : 3
          fpu : yes
          fpu_exception : yes
          cpuid level : 13
          wp : yes
          flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good acc_power nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb bpext ptsc mwaitx cpb hw_pstate ssbd ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic vgif overflow_recov
          bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
          bogomips : 5389.86
          TLB size : 1536 4K pages
          clflush size : 64
          cache_alignment : 64
          address sizes : 48 bits physical, 48 bits virtual
          power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro acc_power [13]

          Comment


          • #25
            Originally posted by zxy_thf View Post
            You need a newer kernel (cannot remember the exact version, but CentOS 7 doesn't have it and Ubuntu 18.04 has).
            Seems that Fedora is being short-sighted - this is Pentium N3700 - it's a 14nm processor, so not that old, and on the higher end of the Airmont family of chips.

            Linux blue 5.3.0-42-generic #34~18.04.1-Ubuntu SMP Fri Feb 28 13:42:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

            cat /proc/cpuinfo
            processor : 0
            vendor_id : GenuineIntel
            cpu family : 6
            model : 76
            model name : Intel(R) Pentium(R) CPU N3700 @ 1.60GHz
            stepping : 3
            microcode : 0x368
            cpu MHz : 720.085
            cache size : 1024 KB
            physical id : 0
            siblings : 4
            core id : 0
            cpu cores : 4
            apicid : 0
            initial apicid : 0
            fpu : yes
            fpu_exception : yes
            cpuid level : 11
            wp : yes
            flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb pti ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat md_clear
            bugs : cpu_meltdown spectre_v1 spectre_v2 mds msbds_only
            bogomips : 3200.00
            clflush size : 64
            cache_alignment : 64
            address sizes : 36 bits physical, 48 bits virtual
            power management:



            Comment


            • #26
              Originally posted by sfx2000 View Post

              Seems that Fedora is being short-sighted - this is Pentium N3700 - it's a 14nm processor, so not that old, and on the higher end of the Airmont family of chips.
              Actually they aren't.
              Thanks to Intel's market segmentation, we will be able to buy new Pentiums/Celerons/Atoms w/o AVX2 support for the next decade(s).
              So there will never be an era that all new chips are supporting AVX2.

              Comment


              • #27
                Enterprises are slow to upgrade processors. The SSE4.1 makes sense. AVX when most tools were never written for it to push vendors to buy new hardware will see more vendors moving away from RHEL, not towards it.

                Comment


                • #28
                  Came here expecting people to be defending their ancient hardware (like usual with these articles) and wasn't let down.

                  As others have said, RHEL is for servers anyway, not outdated and/or low end consumer machines.

                  Comment


                  • #29
                    Originally posted by chithanh View Post
                    Much like the first version of SSE (back when it was still called ISSE), the first version of AVX isn't all that useful for accelerating generic software. Requiring AVX over e.g. SSE4.1 would just exclude a number of CPUs with no real benefit.
                    I don't think they are going to cut off older architectures in order to benefit from modern SIMD instructions. Well, obviously they will, but i think their primary target is using the instruction set as a cutoff point for old cpus. I was promoting the first AVX mainly on that grounds, since i think cpus first released during 2011 would be a nice balanced minimum for a distro released in 2023. 12 years is not too old for a baseline, and does not cutoff useful hardware either.

                    Comment


                    • #30
                      Originally posted by TemplarGR View Post

                      I don't think they are going to cut off older architectures in order to benefit from modern SIMD instructions. Well, obviously they will, but i think their primary target is using the instruction set as a cutoff point for old cpus. I was promoting the first AVX mainly on that grounds, since i think cpus first released during 2011 would be a nice balanced minimum for a distro released in 2023. 12 years is not too old for a baseline, and does not cutoff useful hardware either.
                      AVX2 is a better cut-off point, as it implies a few other extensions as well: BMI1/2, FMA + F16C, MOVBE, ...

                      Comment

                      Working...
                      X