Announcement

Collapse
No announcement yet.

ByteDance Working To Make It Faster Kexec Booting The Linux Kernel

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

  • #11
    I consider TikTok the worst creation of human history, converting teenagers into illiterate and attention seeking (even more than being a teenage) dumb zombies.

    Anyway, every good contribution is welcome. It's only for servers, but better then nothing.

    I would love a massive desktop deployment would improve the Linux desktop ecosystem someday, just like Valve does for gaming tech.

    Comment


    • #12
      Originally posted by RejectModernity View Post
      Autism. All kernel patches get checked 10 times before merging. What should you care about is hardware Israeli-American backdoors in your CPU.
      It's not an either/or thing. Any given person voicing, displaying, or even indirectly associating with minority groups or political dissent can and will be targeted by governments, NGO surveillance, and criminal gangs.

      No people shouldn't be "more worried over X than Y". People should just be worried and take care to protect their digital lives as well as they can by as much prudence as they're capable. Usually that means leaving nation state level attacks largely to protection by professionals (like the forthcoming iOS lockdown mode), but that doesn't mean people should just throw up their hands in helplessness against government overreach - even if that government is China, the US, the UK, or NK. There's plenty to be done at the individual level to protect against fishing-style attacks which is where the majority of breaches occur even when involving nation state aggressors.

      Comment


      • #13
        Originally posted by coder View Post
        A down side would seem to be that hardware can be in an undefined state, making it more likely to hit driver bugs?
        Indeed so. And you'd probably need to weed everything on the hw in question.
        But x86 is mostly harmless as low level stuff (not peripherals) is usually not touched by Linux after it has booted.
        On x86, you poke all the lowlevel platform init stuff outside the kernel (UEFI, Legacy BIOS).

        In other archs, you poke clocks, divisors, serdes and whatnots from platform or device tree configurations usually.
        That level of control usually yields more interesting bugs, as it is repeated with the kernel init.

        Comment


        • #14
          Originally posted by stormcrow View Post
          It's not an either/or thing. Any given person voicing, displaying, or even indirectly associating with minority groups or political dissent can and will be targeted by governments, NGO surveillance, and criminal gangs.

          No people shouldn't be "more worried over X than Y". People should just be worried and take care to protect their digital lives as well as they can by as much prudence as they're capable. Usually that means leaving nation state level attacks largely to protection by professionals (like the forthcoming iOS lockdown mode), but that doesn't mean people should just throw up their hands in helplessness against government overreach - even if that government is China, the US, the UK, or NK. There's plenty to be done at the individual level to protect against fishing-style attacks which is where the majority of breaches occur even when involving nation state aggressors.
          While it's a valid argument that one shouldn't be more worried about X than Y, the original comment does say it's particularly about Chinese companies. It isn't like any other company or government is any good, or like pretty much Linux is made and maintained by governments and companies in practice, so why distrust specifically any given Chinese company if the metric is "not being worried more about X than Y"?

          Comment


          • #15
            Originally posted by milkylainen View Post

            Indeed so. And you'd probably need to weed everything on the hw in question.
            But x86 is mostly harmless as low level stuff (not peripherals) is usually not touched by Linux after it has booted.
            On x86, you poke all the lowlevel platform init stuff outside the kernel (UEFI, Legacy BIOS).

            In other archs, you poke clocks, divisors, serdes and whatnots from platform or device tree configurations usually.
            That level of control usually yields more interesting bugs, as it is repeated with the kernel init.
            Why would interesting bugs be caused by kexec in this case? After all, the initialisation code's job is to put the hardware into a known state no matter the previous state. (Also, what is a divisor and a serde in this context? Divisors I only know from mathematics, and serde I know as a Rust library.)

            Comment


            • #16
              No, ByteDance, you won't earn redemption this way.

              Comment


              • #17
                Originally posted by archkde View Post

                Why would interesting bugs be caused by kexec in this case? After all, the initialisation code's job is to put the hardware into a known state no matter the previous state. (Also, what is a divisor and a serde in this context? Divisors I only know from mathematics, and serde I know as a Rust library.)
                I think you've answered your own question?
                But to clarify. Stable (or unstable) reset state != re-running initialization in software.
                So mishaps do happen.

                Regarding clocks, divisors, plls and SerDes etc. Lowlevel bits.
                There a lot of things going on in platforms that you never ever see, even as a kernel developer.

                It's the same separation between userspace and kernelspace as kernelspace and hardware.
                Shit happens below your feet and you're happy if you can ignore it.

                Comment


                • #18
                  Originally posted by sinepgib View Post
                  - Spot instances for usage spikes (this is probably the most interesting one for optimizing boot speed);
                  - VM migration between instances.
                  Okay, I can see the need to rapidly fire up VM instances in these cases, but their infrastructure would have to be architected around a variety of different VM images, otherwise it seems to me that you'd just leave the same ones running.

                  And I don't really get why you'd do lots of VM migration, in such a cloud service. But, then I have very little knowledge of -- not to mention any experience with cloud computing.

                  Comment


                  • #19
                    Originally posted by coder View Post
                    Okay, I can see the need to rapidly fire up VM instances in these cases, but their infrastructure would have to be architected around a variety of different VM images, otherwise it seems to me that you'd just leave the same ones running.

                    And I don't really get why you'd do lots of VM migration, in such a cloud service. But, then I have very little knowledge of -- not to mention any experience with cloud computing.
                    When you run environments as large as these kinds of companies does you will have hosts dying left and right on a daily basis.

                    Comment


                    • #20
                      Originally posted by archkde View Post
                      Why would interesting bugs be caused by kexec in this case? After all, the initialisation code's job is to put the hardware into a known state no matter the previous state.
                      My assumption is that BIOS/UEFI triggers devices to reset themselves in some fashion. Then, when the kernel's device driver starts interacting with the device, it's essentially starting from a blank slate. I don't know if this is true, however.

                      In contrast, if you merely reset the kernel, then the various devices in the system could be left essentially in their previous state. This could tickle bugs in device drivers that you wouldn't hit in a full reboot.

                      Again, all of this is conjecture. If anyone has actual knowledge to share on the subject, please do.

                      Comment

                      Working...
                      X