Announcement

Collapse
No announcement yet.

Features You Won't Find In The Linux 3.9 Kernel

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

  • Features You Won't Find In The Linux 3.9 Kernel

    Phoronix: Features You Won't Find In The Linux 3.9 Kernel

    While there are many interesting features to the Linux 3.9 kernel, there is some functionality you will not find yet within the mainline Linux kernel...

    http://www.phoronix.com/vr.php?view=MTMyMzQ

  • #2
    That article is a bit disingenuous. Some of those features arent going to make it it into -any- kernel ever.

    Comment


    • #3
      So, if those features are not in 3.9, whats the reason writing about?
      Seems you have a hard time meeting some secret goals of posting frequency you are trying to reach.

      Comment


      • #4
        Originally posted by duby229 View Post
        That article is a bit disingenuous. Some of those features arent going to make it it into -any- kernel ever.
        Back in 2004 a lot of people would have said no one would have changed the O(1) scheduler, but then popular opinion turned against it.

        Comment


        • #5
          Among features that are being actively blocked from inclusion you missed tuxonice. But this article is a pretty nice write-up nice out-of-tree features.
          Why mention not publically worked on stuff (UVD) is beyond me...

          Comment


          • #6
            BFS won't be included unless someone reworks it to make it scalable. In its current state it doesn't scale well beyond 8 CPUs/cores.

            Reliable Nouveau Re-Clocking is the most sought feature on this list.

            Comment


            • #7
              Sad to see reliable re-clicking support for Nouveau isn't on the list.
              Personally, I would really love to see that!

              Lack of AMD UVD support is something that harms AMD, and in the coming months I might buy a new computer, and then AMD won't even be an option.
              Not gonna buy something thats not porno-compatible.

              Personally, I would like to see further ARM multi-platform work.
              Further improvements to the work that was introduced in version 3.7 of the Linux kernel.

              Comment


              • #8
                Originally posted by BO$$ View Post
                Can't they put an if (numCores < 8) { useBFS(); } else { useCFS(); } ?
                They could but they wouldn't want to. Linus has always emphasized that schedulers need to work well across the board to be acceptable. While 8 cores might seem fairly big now, mobile phones will be running that in a few years. None of the mainstream distributions will be interested in a scheduler that isn't generic but only works for some configurations.

                Comment


                • #9
                  Con Kolivas has some ideas to make the scheduler scalable by automaticly trickling down queues. But he has no time. No one is sponsering him ....

                  Comment


                  • #10
                    Originally posted by phoronix View Post
                    Phoronix: Features You Won't Find In The Linux 3.9 Kernel

                    While there are many interesting features to the Linux 3.9 kernel, there is some functionality you will not find yet within the mainline Linux kernel...

                    http://www.phoronix.com/vr.php?view=MTMyMzQ
                    Michael, you forgot Clang Support, DTrace, OSSv4, PaX/GrSecurity r8168, UnionFS, YAFFS2 and ZFS.

                    By the way, I find ZFS to be more maintainable outside Linus' tree. The PaX/GrSecurity developers feel similarly about their things. Michael should probably consider whether or not these things into Linus' tree makes sense before writing these articles.
                    Last edited by ryao; 03-10-2013, 05:39 PM.

                    Comment


                    • #11
                      Originally posted by BO$$ View Post
                      So basically we're stuck with CFS which is inferior to whatever Windows is using and produces worse behavior and then wonder why linux cannot take on Windows?
                      So why don't you donate some money for BFS development?

                      Comment


                      • #12
                        Originally posted by BO$$ View Post
                        So basically we're stuck with CFS which is inferior to whatever Windows is using and produces worse behavior and then wonder why linux cannot take on Windows?
                        The CFS works well for most workloads with the automatic cgroups patch that was merged around 3.3. Performance lags likely originate in things like the kernel's page replacement algorithm and the block/buffer/VFS/filesystem IO stack. Speaking of which, ZFS is designed to replace most of that. I maintain/develop the Gentoo Linux ZFS packages, so I tend to hear how it works for people. People that migrate to ZFS usually find that their systems are more responsive on ZFS. The only person that did not see an improvement in interactive response had more RAM than storage, which kept everything cached in RAM no matter what he did.

                        Comment


                        • #13
                          Originally posted by BO$$ View Post
                          When I turned to linux I formatted my partitions with ext4 since that is what it seemed to be the default. Changing the filesystem is pretty hard right now and I don't want to reformat my HDD. Why isn't ZFS the default then? My mouse stuttering for example doesn't always happen when I run out of memory and have to swap but it's true that swapping tends to degrade performance really bad. Waaay worse than in windows. Even when swapping I could still listen to music and have a continuous mouse movement. It's really frustrating when I hear people bolstering how great the linux kernel is, a magnificent piece of engineering, when I can't do basic stuff with which I never had a problem in Win 98 even.
                          The "default filesystem" is a distribution decision. It has nothing to do with the Linux kernel. Getting any distribution to change its filesystem recommendations are hard. It basically needs to be a drop-in replacement that does things better with zero regressions in even the most obscure scenarios before anyone would consider it. ZFS is the best overall filesystem, but getting a distribution to switch to ZFS will be hard as long as there is a single area where its incumbent filesystem works better. ZFS' main weaknesses are in memory management, architecture support and partition management. Basically, ZFS won't work on the WRT54G and it really isn't compatible with existing installers, like anaconda. I do not expect many distributions to switch to ZFS until those issues are fixed. There is nothing stopping end-users from jumping ship early though.

                          With that said, the continuous mouse movement that you observed while playing music on Windows likely can be attributed to having the display server in the kernel. Things that live in the kernel are always resident, which insulates them from the effects of disk thrashing. Windows put all of the components required to draw the cursor on your screen into the NT the kernel, which is the reason why it performed so well. In the case of Linux, the display server and compositor live in userland, so the kernel can page them out to a swap device as it pleases. This is likely why you experience lags. Some people think that changing the CPU scheduler will help, but the effect that a CPU scheduler has on this is fairly chaotic in nature. The proper way of handling this would be to use a more intelligent page replacement algorithm.

                          ZFS has ARC, which tends to handle this more gracefully. Unfortunately, there are some outstanding memory management issues that prevent it from handling this as well as it could. Specifically, the Linux kernel's virtual memory support is awful. It lacks support for slab-based allocations, all allocations use a single lock and it does not obey GFP flags. LLNL wrote a compatibility shim that attempts to handle this, but it is far from ideal. In addition, mmap() is currently double cached between the page cache and ZFS ARC, which can create churn in the kernel as the kernel evicts pages required for your display server only to load them back from ARC. Admittedly, this is better than going to disk, but it still degrades performance.

                          Comment


                          • #14
                            Using BFS for desktop users should be OK, as they generally have at max a 4core+4HTT system . Servers have >8 cores, and they need the throughput and scalability of CFS.
                            Desktop users generally need responsivity.

                            Comment


                            • #15
                              Originally posted by mayankleoboy1 View Post
                              Using BFS for desktop users should be OK, as they generally have at max a 4core+4HTT system . Servers have >8 cores, and they need the throughput and scalability of CFS.
                              Desktop users generally need responsivity.
                              Most of the scenarios where people claim that BFS helps seem to involve disk IO. While the more greedy nature of BFS might have an effect on the behavior of the kernel's page replacement algorithm, it does not address actual IO problems.

                              Comment

                              Working...
                              X