Announcement

Collapse
No announcement yet.

The Huge Disaster Within The Linux 2.6.35 Kernel

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

  • 'poor reaction'?
    Al Viro was third in the thread and:

    Cute... Frankly, I'd be fine with just reverting that one and teaching
    selinux to STFU. However, I wonder what specifically is getting polled.
    Which anon_inode users?

    Does anybody have strace handy?

    doesn't look like a 'poor reaction'.

    Comment


    • Originally posted by nzjrs View Post
      Look how poorly they reacted when the regression was raised.

      http://lkml.org/lkml/2010/5/22/150
      That was an independent statement regarding an issue that had been found. At this stage, it is unclear if this is the same regression (via a private thread). Or even the train of analysis is correct for the issue Michael raised.

      Identifying a regression (even just pointing to the Phoromatic tracker) would have had the usual mix of "the benchmark is pointless", "it's ubuntu, not the kernel" sorts of discussions. I've been through it a few times already.

      Comment


      • well, one problem with ubuntu: since there are no kernel hackers employed by Canonical, there are no kernel hackers using ubuntu. If you have a problem while using Fedora, opensuse etc the chances are a lot better.
        And when reporting problems with gentoo I always got either no reaction at all - or patches to try out

        Comment


        • 1. This article contains useful information that it's nice to see publicized.
          2. It would have been nice to see more in-depth analysis of the cause, but this is by no means necessary since the information is useful on it's own. Top tier websites like Ars or Anantech would have gone deeper into the details, but I understand that those websites also have a lot more resources than Phoronix.
          3. Most of the people are only complaining because of the title. Change that, and you have no problems. The issue is that the title reads like a tabloid - what disaster did Michael even find? If this regression was released in the final 2.6.35 kernel, that would be a disaster. A regression during the merge window that can easily just be backed out before even RC1 hits? Not a disaster, not even unexpected. The title seems intended solely to drive page views by promoting sensationalism, which is why most people are critical. Judging by the number of comments here, it seems like it may have succeeded, though, so I suppose we'll be seeing more of these in the future.

          Comment


          • Originally posted by energyman View Post
            If you have a problem while using Fedora, opensuse etc the chances are a lot better.
            I find pretty much the same here. There have been many times where I have found reporting an issue with the kernel to a distro that has kernel devels in it will result in quicker resolution.

            Comment


            • Well, they bisected the commit and found the bug having entered the tree on May 22. According to the thread on lkml the bug has now been fixed!

              Nothing to see here, move along.

              Comment


              • At least we made >10k views and lots of $$$ for phoronix. Maybe they should hire a kernel or xorg developer to provide insider info for better quality articles.

                Comment


                • Why not bind the kernel tracker to handle these automatically?

                  Something like:
                  if regression found & over x %, wait y days, if still there, bisect, and email whoever is to blame.

                  Comment


                  • Originally posted by curaga View Post
                    Why not bind the kernel tracker to handle these automatically?

                    Something like:
                    if regression found & over x %, wait y days, if still there, bisect, and email whoever is to blame.
                    Not a bad idea. Devs might not want impersonal, possibly unwanted, automatically generated messages though. They're less likely to pay attention to such messages - especially those who might not know about Phoronix. Better would be simply for kernel devs to pay attention to the service if they find it useful/valuable.

                    opt-in is probably better than opt-out.

                    Comment


                    • I'll just add that it should include positive regressions as well; I know I would like to have an email saying my patch increased XYZ by 15%

                      Comment


                      • Originally posted by not.sure View Post
                        At least we made >10k views and lots of $$$ for phoronix. Maybe they should hire a kernel or xorg developer to provide insider info for better quality articles.
                        Or perhaps one company whose business is based on Linux could contract Phoronix/sponsor Phoromatic and/or have someone actually watch the results and handle such regressions. You know, for better quality kernels.

                        Comment


                        • Originally posted by tkjacobsen View Post
                          Well, they bisected the commit and found the bug having entered the tree on May 22. According to the thread on lkml the bug has now been fixed!

                          Nothing to see here, move along.
                          Can you provide a reference to the reversion and the mailing thread?

                          Comment


                          • Michael, now after the bug was fixed...any improvement noted by Phoromatic yet?

                            Comment


                            • As we have already shown before, using the Phoronix Test Suite and its components we can also narrow down to the individual commit(s) that introduced these serious performance issues by layering the Phoronix Test Suite's automated support atop the git-bisect command to automatically traverse the tree and perform tests at each step of the process. We may do so again in this instance -- time or incentive permitting -- to track down this newest problem. Alternatively, you can too since the Phoronix Test Suite is indeed open-source. It is already can be as simple as installing a kernel prior to 2010-05-20, a post-2010-05-22 kernel, and then running a command like phoronix-test-suite benchmark hmmer.
                              So, where's the offending commit pinpointed? I'm not even a kernel developer, and I would have been interested in reading the attached changelog.

                              Also, finding such commit would have made much more impact, specially if sent to mailing list -- "so there I have this commit, when I merge it applications X, Y and Z are 50% slower. Explain that to me.".
                              The answer to that can't be "Ubuntu's bloatness is to blame".

                              Comment


                              • Originally posted by V!NCENT View Post
                                r600g wasn't merged to mesa. So scrapt these articles then?
                                Bridgman and others do not add very interesting info on not released drivers?

                                What else does not matter at all? All I see is nin pages full of "why did you report a development bug?"

                                Can I have my WTF back now? I might need it in the future where you might comment on Mesa, KDE and Gnome development.
                                The strange and funny thing is you're according to some other articles. You sound very sad also :> You shoud rather say: "why didn't you report a development bug". Btw. some people who're talking about Linux development model have no idea about it. There are no more "stable" releases (you can call, and they're called stable at kernel.org etc, but it's a different thing). Those are distros which should take a proper kernel. All this bitching about Linux development model which scares some people is plain stupid and it's very succesfull.

                                Comment

                                Working...
                                X