Announcement

Collapse
No announcement yet.

Heterogeneous Memory Management Is Still Planning For Linux 4.12

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

  • Heterogeneous Memory Management Is Still Planning For Linux 4.12

    Phoronix: Heterogeneous Memory Management Is Still Planning For Linux 4.12

    If longtime open-source Linux graphics developer Jerome Glisse has his way, the long-awaited Heterogeneous Memory Management (HMM) support will be merged for the Linux 4.12 kernel...

    http://www.phoronix.com/scan.php?pag...For-Linux-4.12

  • #2
    Yet again more innovation from NVIDIA for the open source stack that the community seems to work against/ignore because their religious leaders has given them the finger at one point in time(wow that was a rush when he did that). Do we have more information on why it is being delayed exactly?

    Comment


    • #3
      Originally posted by cj.wijtmans View Post
      Yet again more innovation from NVIDIA for the open source stack that the community seems to work against/ignore because their religious leaders has given them the finger at one point in time(wow that was a rush when he did that). Do we have more information on why it is being delayed exactly?
      because it really intrusive in a very core part of the kernel and touches the memory subsystem quite substancially(from what i get of course, i can be wrong but seeing andrew morton is speaking is for sure core code enough), anything that touches core parts of the kernel is guaranteed to take a long time to get merged and several revision.

      after 18 revisions should be close enough for 4.12-4.14 timeframe unless something brakes core code which is a big no no, specially coming from andrew since linus won't touch it with a 18m pole.

      there are no religious "leaders" in the kernel, either your code is good enough and you provide enough guarantee for its maintenance or you can be god but your code won't be ever merged, it is that simple and that won't change as long as linus and other kernel maintaners do their work properly.

      Comment


      • #4
        Originally posted by jrch2k8 View Post

        because it really intrusive in a very core part of the kernel and touches the memory subsystem quite substancially(from what i get of course, i can be wrong but seeing andrew morton is speaking is for sure core code enough), anything that touches core parts of the kernel is guaranteed to take a long time to get merged and several revision.

        after 18 revisions should be close enough for 4.12-4.14 timeframe unless something brakes core code which is a big no no, specially coming from andrew since linus won't touch it with a 18m pole.

        there are no religious "leaders" in the kernel, either your code is good enough and you provide enough guarantee for its maintenance or you can be god but your code won't be ever merged, it is that simple and that won't change as long as linus and other kernel maintaners do their work properly.
        I was just trolling. It was more of a reference to a lack of commitment towards GLVND and EGLStreams.

        Comment


        • #5
          Originally posted by cj.wijtmans View Post

          I was just trolling. It was more of a reference to a lack of commitment towards GLVND and EGLStreams.
          gotcha.

          about GLVND dunno what you mean, mesa support it since a while ago and several distro are starting to enable it by default like next fedora(i think) and for sure Archlinux(check archlinux.org)

          about EGLStreams i'm particularly on the no way side tho, i don't believe it offers anything better than GBM, is a standard sure but kinda absolutely unknown and unsupported basically everywhere but nVidia and most particularly is a huge vendor locking potential if it get too mainstream.

          in this department i prefer a joint nVidia/mesa agreement on complementing GBM whereas is weak instead of having 2 partial solutions(current GBM and EGLStreams)

          Comment


          • #6
            Anybody know if winders has an HMM equivalent? Or is this feature Linux specific at the moment?

            Comment


            • #7
              Originally posted by cj.wijtmans View Post
              Yet again more innovation from NVIDIA for the open source stack that the community seems to work against/ignore because their religious leaders has given them the finger at one point in time(wow that was a rush when he did that). Do we have more information on why it is being delayed exactly?
              Do you have any idea how important the memory manage is in the kernel? I would expect such a major change to take years to implement. Frankly I believe the kernel maintainers want to see this feature implemented because it offers the possibility of really good performance increases for some code bases. The problem is you can't corrupt the kernel's memory manager as that would absolutely destroy reliability.

              Comment


              • #8
                No it wouldnt. You dont use new kernels for stability, that is stupid.

                Comment


                • #9
                  Originally posted by jrch2k8 View Post
                  about EGLStreams i'm particularly on the no way side tho, i don't believe it offers anything better than GBM, is a standard sure but kinda absolutely unknown and unsupported basically everywhere but nVidia and most particularly is a huge vendor locking potential if it get too mainstream.

                  in this department i prefer a joint nVidia/mesa agreement on complementing GBM whereas is weak instead of having 2 partial solutions(current GBM and EGLStreams)
                  The EGLStreams vs GBM dispute ended up in acknowledging that both have some flaws, and deciding to create a new Unix Device Memory Allocator, which for some reason has no activity since the last year, as of writing these words.

                  Comment


                  • #10
                    Originally posted by cj.wijtmans View Post
                    No it wouldnt. You dont use new kernels for stability, that is stupid.
                    Yes it would, and no it would not be funny.
                    We aren't talking of a leaf like a file system or a GPU driver that are modules, but of a core kernel feature, if this causes instability it will cause instability for all, not for a subset of users.

                    For testing new stuff there are branches and kernel patches and custom kernels, there is no real reason to impose high risks like this on everyone for the sake of development. This is Linux, not Windows 10.

                    Comment

                    Working...
                    X