Announcement

Collapse
No announcement yet.

Ubuntu 9.10 Off To A Great Performance Start

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

  • #16
    Originally posted by Luis View Post
    Ok, so since everyone is trying to guess here, I'll try my guess too:

    Could the performance improvements (they are most notable in I/O operations) be due to changing the default in ext3 from date=ordered to data=writeback? In other words, anyone could have enjoyed these improvements years ago, as long as they don't care about a few safety/security problems when mounting the filesystem with data=writeback.

    Well, at least one of those safety problems have been addressed so you won't get zeroed files if a crash happens just after a file is renamed/replaced by a program that does not use sync. Still, you might get files from other users (or other users can get files belonging to you).
    Correct me if I'm wrong, but data=writeback is in the default kernel. The one used in the benchmarks however is rebranded, are you sure Ubuntu doesn't fall back to data=ordered, like predicted by Corbet at least for some time?

    Comment


    • #17
      I have to give Michel a lot of credit for this article. It's significantly better than the last article about Ubuntu 9.10 (the Intel graphics regressions) that I complained about so loudly. There's some good discussions about why performance improved. I particularly like the discussion about the MySQL test. This is a great step forward. Keep it coming Michel, and of course, the entire Ubuntu team.

      Comment


      • #18
        Originally posted by bugmenot View Post
        Great to see the Kernel devs making an effort to improve the desktop experience ... makes me tempted to upgrade to the 2.6.30 kernel on Jaunty (not sure if thats possible)

        It should be.

        Use the kernel-package program.

        What you do is basically this:
        1. download the source code from kernel.org. Untar it to /usr/src

        2. in the linux-2.6.30 directory, copy your /boot/config-2.6.29-whatever to /usr/src/linux-2.6.30/.config

        3. Run 'make oldconfig'

        Answer any questions that pop up. If it asks questions it is because of features in 2.6.30 that are not in 2.6.28-whatever-the-hell-it-is. If you don't know the correct answer, choose the default as it's the safest setting.

        What this does is that you get as close as possible to original kernel's configuration.

        Then run the make-kpkg stuff.


        Something like this:

        make-kpkg clean
        make-kpkg --config=menuconfig kernel_image modules_image

        What this does is that it compiles the kernel and packages it into debian packages. Then you just install the .deb package.

        What this does is that it allows you to remove your current kernel (which I don't recommend) it fullfills any package dependences and it'll run all the hooks to configure grub and all that when you install it.

        Also it makes it easy to uninstall it.

        That is about the safest way to build a custom kernel. Just remember if it doesn't work then you can go back to the original one.

        good luck.
        Last edited by drag; 05-16-2009, 12:48 AM.

        Comment


        • #19
          Worth mentioning that new kernels default to ext3 in writeback mode rather than ordered, I'm guessing that's where all your disk improvements come from.

          Comment


          • #20
            @drag

            When you use root=UUID=... then you should compile kernels with initrd support (--initrd option). Also intersting is to compile a kernel from Ubuntu git, when you add a git pull master you can update em to latest code. Currently merging is a bit tricky, but not impossible. I packaged -5 kernels updated to rc6 for Kanotix. There you see the changes in U git:

            http://kernel.ubuntu.com/git?p=ubunt....git;a=summary

            Needed packages:

            sudo apt-get install git-core kernel-package kernel-wedge debhelper build-essential devscripts makedumpfile fakeroot

            To checkout:

            git clone git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git

            To update:

            git pull git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git master

            edit the files which fail to merge (seek for <<<< and >>>>), most of the times it is straight forward. Then

            git add file-1-edited file-2-edited

            git commit

            to compile the generic kernel:

            time fakeroot debian/rules binary-debs flavours=generic skipabi=true skipmodule=true

            missing package for header:

            time fakeroot debian/rules binary-headers
            Last edited by Kano; 05-16-2009, 07:57 PM.

            Comment


            • #21
              Awesome.

              Hopefully AMD will have either closed or open source driver support for my 4850 X2 under newer versions of Linux by then including for 2.6.28 (Jaunty). :X

              Whatever happened to the "same day support" stuff. :P
              Last edited by Yfrwlf; 05-17-2009, 11:52 AM.

              Comment


              • #22
                Same day support with Catalyst drivers was for new GPUs, not for new OS versions.

                For new kernel / X / distro versions we said that we expected gradual reduction of the time from new kernel/server/distro availability to Catalyst support, although our first priority will still be the enterprise distros most of our customers use.

                Support for 9.04 is currently at "early look" stage per the release notes, ie it runs but has not been through a full engineering/QA pass. I don't think we have been able to repro the X2 problems on our systems yet, so accumulating good information in a Bugzilla ticket (one, not many) will help the developers. I took a look through the Bugzilla system and didn't see *any* applicable tickets, so creating one would be a good start.

                This appears to be a regression related to Jaunty but even that info is not 100% consistent, so accurate info about "works with this combionation, doesn't work with that combination" will help.
                Last edited by bridgman; 05-17-2009, 12:21 PM.

                Comment


                • #23
                  Originally posted by bridgman View Post
                  Same day support with Catalyst drivers was for new GPUs, not for new OS versions.
                  OK, I'll certainly give you that, and Ubuntu even had a notice saying that upgrading to the newer version would break your closed source graphics drivers.

                  However, while it is impossible to track what random devs are rolling out, a new X server isn't really random and is what AMD needs to be tracking any way. Hopefully things will be a lot better and easier with Gallium3D, but it just would have been nice to see better communication and tracking in this situation between AMD and X Server 1.6, but I guess you sort of address that in the next comment...

                  Originally posted by bridgman View Post
                  For new kernel / X / distro versions we said that we expected gradual reduction of the time from new kernel/server/distro availability to Catalyst support, although our first priority will still be the enterprise distros most of our customers use.
                  What is needed is tracking of X, and standardisation among distros, for both the open and closed drivers. Linux users shouldn't have to worry about what distro they are running, nor should AMD, because there should be standards in place to allow for universal easy Linux driver installation. I hope AMD is helping to push for that, maybe even help plan/program such a thing to help it come to pass faster. Partnering with other companies to get this done would of course be best.

                  Originally posted by bridgman View Post
                  Support for 9.04 is currently at "early look" stage per the release notes, ie it runs but has not been through a full engineering/QA pass. I don't think we have been able to repro the X2 problems on our systems yet, so accumulating good information in a Bugzilla ticket (one, not many) will help the developers. I took a look through the Bugzilla system and didn't see *any* applicable tickets, so creating one would be a good start.
                  In other words, to continue from what I said above, it shouldn't be AMD's problem to fix a distro, it should be that distro's problem to correctly follow the standards and protocols the community brings to bare. AMD should only have to follow standards and help push for better ones. Track Xorg and the kernel and any other important APIs your driver needs to correctly interface with or whatnot, and be done with it.

                  I've created and added to bugs about this issue on Launchpad, which is a fairly nice bug tracking system that I like, but I'm sure there are many others. I haven't created any bugs anywhere else yet like for X Server or whatnot.

                  Originally posted by bridgman View Post
                  This appears to be a regression related to Jaunty but even that info is not 100% consistent, so accurate info about "works with this combionation, doesn't work with that combination" will help.
                  Yep, I've filed bugs already, thanks for the suggestion though.
                  Last edited by Yfrwlf; 05-17-2009, 06:48 PM.

                  Comment


                  • #24
                    Originally posted by Yfrwlf View Post
                    What is needed is tracking of X, and standardisation among distros, for both the open and closed drivers. Linux users shouldn't have to worry about what distro they are running, nor should AMD, because there should be standards in place to allow for universal easy Linux driver installation. I hope AMD is helping to push for that, maybe even help plan/program such a thing to help it come to pass faster. Partnering with other companies to get this done would of course be best.
                    Won't happen, with linux you have too many distro's with differing POV's. They have tried standardization, it's called the LSB, but again you have a bunch of pig headed people in the distro's that seem to see that as a "infringement of freedom of choice" and let politics such as community developed vs corp developed distros inpeed the much needed standardization of key base foundations. Anybody remember United Linux and how it failed?

                    In other words, to continue from what I said above, it shouldn't be AMD's problem to fix a distro, it should be that distro's problem to correctly follow the standards and protocols the community brings to bare. AMD should only have to follow standards and help push for better ones. Track Xorg and the kernel and any other important APIs your driver needs to correctly interface with or whatnot, and be done with it.
                    You will NEVER get the stubborn opensource community to be co-operative with closed source drivers. When it comes to that stuff they are extremely pig headed. Proprose such a thing and they will cry "We can't fix their crap, screw them." Closed sourced developers have tried to get a bit of help in area's to ensure compatibility instead they are greated with "Fuck you". Nvidia has accepted that and they don't expect any help from the X community at all anymore.

                    Comment


                    • #25
                      That's a damn shame. Instead of people just getting something that works and make it their own they should just improve that software. Unity is key.

                      Comment


                      • #26
                        Originally posted by Yfrwlf View Post
                        What is needed is tracking of X, and standardisation among distros, for both the open and closed drivers. Linux users shouldn't have to worry about what distro they are running, nor should AMD, because there should be standards in place to allow for universal easy Linux driver installation. I hope AMD is helping to push for that, maybe even help plan/program such a thing to help it come to pass faster. Partnering with other companies to get this done would of course be best.
                        There is already a standard in place allowing for "universal easy Linux driver installation". It's called "open source code".
                        Unfortunately with closed-source drivers such as fglrx, only the vendor has the ability to get the driver tracking the evolving X APIs. This is why the open source radeon/radeonhd drivers already work with the new X server.
                        Originally posted by Yfrwlf View Post
                        In other words, to continue from what I said above, it shouldn't be AMD's problem to fix a distro, it should be that distro's problem to correctly follow the standards and protocols the community brings to bare. AMD should only have to follow standards and help push for better ones. Track Xorg and the kernel and any other important APIs your driver needs to correctly interface with or whatnot, and be done with it.
                        Nope. It's the distro's job to package the software for easy installation (and to develop packaging tools etc.).
                        If all hardware companies followed the "open source" (and open specs) linux standard for hardware support, then there would be no problem. AMD's currently doing the right thing by releasing code and hardware specs, but it will take time for hardware support to mature.

                        Comment


                        • #27
                          Originally posted by deanjo View Post
                          You will NEVER get the stubborn opensource community to be co-operative with closed source drivers.
                          I think you'll find it's the other way around. Ever read the nv driver code?
                          Originally posted by deanjo View Post
                          When it comes to that stuff they are extremely pig headed. Proprose such a thing and they will cry "We can't fix their crap, screw them."
                          Other way round again I think. Taking the nvidia driver for example, instead of contributing to an open acceleration architecture in X such as EXA or UXA, they went and implemented their own proprietary solution.
                          Originally posted by deanjo View Post
                          Closed sourced developers have tried to get a bit of help in area's to ensure compatibility instead they are greated with "Fuck you". Nvidia has accepted that and they don't expect any help from the X community at all anymore.
                          Bullshit. Provide a link to this "Fuck you" quote.
                          Closed source developers get amazing support when they decide to reach out to the open source community. For example, how else has there been such rapid support for VDPAU provided in Xine, MPlayer, VLC, FFmpeg and others? It was only announced in November last year!

                          Comment


                          • #28
                            I'm intrested in the boot time of the new ubuntu alpha. Fastboot(async hardware probing) from the Intel Moblin project is enabled by default from kernel 2.6.30. This would in theory speed up the bootup process. I'm curious for real life examples.
                            Last edited by bugmenot; 05-18-2009, 07:12 AM.

                            Comment


                            • #29
                              Originally posted by krazy View Post
                              Bullshit. Provide a link to this "Fuck you" quote.
                              Closed source developers get amazing support when they decide to reach out to the open source community. For example, how else has there been such rapid support for VDPAU provided in Xine, MPlayer, VLC, FFmpeg and others? It was only announced in November last year!
                              Exactly. Guess who helps nvidia making their installer? OS community

                              Comment


                              • #30
                                Originally posted by deanjo View Post
                                Won't happen, with linux you have too many distro's with differing POV's. They have tried standardization, it's called the LSB, but again you have a bunch of pig headed people in the distro's that seem to see that as a "infringement of freedom of choice" and let politics such as community developed vs corp developed distros inpeed the much needed standardization of key base foundations. Anybody remember United Linux and how it failed?

                                You will NEVER get the stubborn opensource community to be co-operative with closed source drivers. When it comes to that stuff they are extremely pig headed. Proprose such a thing and they will cry "We can't fix their crap, screw them." Closed sourced developers have tried to get a bit of help in area's to ensure compatibility instead they are greated with "Fuck you". Nvidia has accepted that and they don't expect any help from the X community at all anymore.
                                That's extremely hurtful to all who are involved with Linux. A lack of standards hurts everyone, including open source programs as well, as constant recompilation shouldn't be required and isn't something normal users can do, the ones that Linux is trying to target now for it to ever be popular on the desktop.

                                Linux should be all about standards, it's ironic that standards are pushed heavily in other areas, and that lock-in is looked down upon, yet in critical areas like package management, the lack of standards is awful and heavily impedes everyone's freedoms, yet it's perfectly OK?

                                You know what I think, is that distros and the companies behind them don't want a Linux program to be a Linux program, they don't want to respect the developers and use the code as they intended it and rename the program to something else if they change it, they want to keep Linux a moving target and keep package management proprietary to their versions of their own "distro". The problem is, if you could just go download *Firefox*, and it would be *Firefox from Mozilla*, or if you downloaded Xorg, and it would be the original thing from those devs, if all Linux software was clearly labeled with packages that had clear dependencies on the *original* versions of other programs, what would that mean?

                                Distros would die. Those companies would die with them unless they focused on their other ways of making money. There would no longer need to be a "distro" because it would all be Linux, and no one would have to beg a distro for a repository so they could install software. Instead they could go directly to the source, the devs/community, or use any one of a billion different Linux software mirrors that *anyone* can use regardless of what they were running as long as it was Linux.

                                Diversity is good, competition is great, and the various differences in Linux ARE good, don't get me wrong. What is bad is when things aren't labeled, when the sources for software aren't respected, so as to keep everyone on the same page and to give the software projects that are most widely used their appropriate light and attention from the community. Those individual software projects should be the focus of the community, NOT a distro, like they're so special when all they did was compile what some dev's offered just because of the refusal to
                                make a universal Linux packaging system/format.

                                Originally posted by krazy View Post
                                There is already a standard in place allowing for "universal easy Linux driver installation". It's called "open source code".
                                You point out something important here, which is that traditionally a lot of the modularity in Linux allowing for compatibility and interoperability has been implemented on the source code level. I understand that. However, that way sucks, because it would mean users have to *compile* to get that compatibility. If Linux is going to be a desktop OS for normal users, while having complete freedom to install what they want, this can't stand.

                                For now, this is what will have to happen to solve this problem as far as I can figure:

                                1) Programs which are very modular need to work on creating an ABI for their core system, if possible and if it is felt necessary, meaning plugins. Lets take imagemagick as an example:
                                a) core imagemagick program - the core bit that everyone will use, and should not be modified. If it is, like with any program, a different name for the program should be used.
                                b) jpg support - should be a module, if the intention is to cut down on size, etc
                                c) png support - etc
                                2) Because of the fact that space isn't so much an issue any more with computers these days, the developers may choose to wrap nearly all or all of their library into one big package. Either way, have a clear naming convention so that other packages can correctly call upon your program's name and version number if it's a dependency.
                                3) Package your software using at least one universal Linux packaging format so that ALL Linux users, not just Ubuntu users, will have access to your software. Help create a universal packaging format/API/ABI/whatever that all packaging managers can adopt if needs be. Don't release your code for a proprietary system, demand standards so everyone can be free to use it.

                                IMO, as I said before, I blame the distro companies for not wanting this to happen, otherwise they lose some of the power and uniqueness that many of them currently have. The solution for these companies is to:

                                1) Be a support company for Linux as a whole.
                                2) Be a development/bounty company for Linux as a whole.
                                3) Get your "own" software project(s) and back it/them, or in other words provide specialised and focused development and support of one or more software projects, like so many other companies do.
                                4) Kill the term "distro", and instead provide your images as they were intended: as "just another specific selection of Linux software that we like to have as our base OS installation, but feel free to easily install software from any repository or any website to add to it, as we support Linux packaging standards so you can do that".

                                Linux can either continue jailing it's users who don't know how to compile, or it can get in gear with the 21st Century, and provide real freedom by simply respecting the community and it's developers and users and getting a system together for real software sharing.

                                Originally posted by krazy View Post
                                Nope. It's the distro's job to package the software for easy installation (and to develop packaging tools etc.).
                                Who are you, the Linux software foreman? I know how it works now, believe me, and I'm saying that the way it works now sucks. Linux will remain fragmented if things stay that way. "Sorry, you have to reinstall this different Linux OS if you want this software, because it's not in the repositories." How many times have you wanted, say, a newer version of OOo, or to try out a newer Xorg, or a newer <insert program here>, but couldn't because they only offered source code? Maybe you're totally OK because you love spending all your time searching for dependencies so you can spend all your electricity re-compiling programs that should have only needed to be compiled once by the actual developers of the programs or for anyone interested in software development?

                                The way Linux is now sucks, and if you want to support freedom for desktop users, or any users that don't want to bother with compiling software like I do, then you will support a unified package format and for it to be adopted by the current popular package managers. I want Linux to grow exponentially, not be artificially be walled off from one another, unable to easily share programs with each other and for dev's to share programs with the community, just because some retarded companies refuse to help the community make some real standards for packaging and adopt them out of fear that they won't be relevant any more if no one is forced to come to them begging for software that should be easily freely available directly from the real devs.

                                Oh, and btw, you don't even need to bother with a "no this feature is not needed!" response, because if you want to continue compiling your own programs, be my guest. Linux needs to continue to be an environment that makes compilation easy, even a lot easier than it is now, to help spur Linux software development. But, this feature would in no way prohibit you from doing so. This would be a *feature* that should be added. There is no harm in that. This whole system causes nothing but frustrations for not only end users, but developers, especially when distro #73258 user #3 comes crawling to them with a bug that is completely not their fault because this distro modified their program without renaming it and introduced bugs into it.
                                Last edited by Yfrwlf; 05-18-2009, 08:07 AM.

                                Comment

                                Working...
                                X