Announcement

Collapse
No announcement yet.

KTask Revived For Providing In-Kernel Multi-Threading For CPU Intensive Tasks

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

  • KTask Revived For Providing In-Kernel Multi-Threading For CPU Intensive Tasks

    Phoronix: KTask Revived For Providing In-Kernel Multi-Threading For CPU Intensive Tasks

    It's been just about one year since the last patch series was sent out while on Monday marked a new revision to KTask, the effort that provides a generic framework to parallelize CPU-intensive kernel work...

    http://www.phoronix.com/scan.php?pag...l-Multi-Thread

  • #2
    I've read the entire news piece and I still cannot figure out why this thing is needed and why the built-in kernel scheduler cannot do it.

    Comment


    • #3
      It sounds like a thread pool that's specialized for data parallelism, without any features like work-stealing (which may not be that useful in these scenarios). So it doesn't seem particularly fancy.

      Comment


      • #4
        Originally posted by birdie View Post
        I've read the entire news piece and I still cannot figure out why this thing is needed and why the built-in kernel scheduler cannot do it.
        Did seem to be a bit thin.

        Does anybody know know why it was dropped in the first place?

        Comment


        • #5
          Originally posted by wizard69 View Post
          Does anybody know know why it was dropped in the first place?
          Based on the phrasing "it's great to see the code revived", I assume it was left un-maintained for a while.

          Comment


          • #6
            Originally posted by schmidtbag View Post
            Based on the phrasing "it's great to see the code revived", I assume it was left un-maintained for a while.
            Yeah just took a year for new code revision to be published... Presumably as the Oracle dev was busy with other work.
            Michael Larabel
            http://www.michaellarabel.com/

            Comment


            • #7
              Seam nice, especially if it speed up other thing than the most useless thing to speed up (the boot, because I don't use my system for just loop reboot, in that case uefi and SCSI/SAS initialization optimization would be a bigger priority ).

              Comment


              • #8
                If it can be sped up through cpu paralization, it doesn't really belong in the kernel.

                ​​

                Comment


                • #9
                  Originally posted by RavFX View Post
                  Seam nice, especially if it speed up other thing than the most useless thing to speed up (the boot, because I don't use my system for just loop reboot, in that case uefi and SCSI/SAS initialization optimization would be a bigger priority ).
                  Neither does enterprise practise boot loops. LSI's SAS RAID controllers could just themselves take like 2 minutes to initialize. It's one thing enterprise does not care about because reboots are few .

                  Comment

                  Working...
                  X