On Tue, Jun 01, 2010 at 12:19:29AM +0100, Alex Buell wrote:
> http://www.phoronix.com/vr.php?view=14976
>
> Question: Why?
One of the theories that has been advanced is that it's simply this
problem:
http://lkml.org/lkml/2010/5/22/154
If so, it points out how idiotic Phoronix is about not being able to
notice udev pegging the CPU at 100% being someone bad for its
benchmark runs. :-)
OTOH, this bug has been known for over a week, and it is sort sad that
we haven't reverted this patch. It looks like the conversation has
died, but without a fix?
- Ted
On Tue, Jun 1, 2010 at 7:10 AM, <[email protected]> wrote:
> On Tue, Jun 01, 2010 at 12:19:29AM +0100, Alex Buell wrote:
>> http://www.phoronix.com/vr.php?view=14976
>>
>> Question: Why?
>
> One of the theories that has been advanced is that it's simply this
> problem:
>
> ? ? ? ?http://lkml.org/lkml/2010/5/22/154
>
> If so, it points out how idiotic Phoronix is about not being able to
> notice udev pegging the CPU at 100% being someone bad for its
> benchmark runs. ?:-)
>
> OTOH, this bug has been known for over a week, and it is sort sad that
> we haven't reverted this patch. ?It looks like the conversation has
> died, but without a fix?
It's fixed by 1eb2cbb6d5efe129 so the problem doesn't exist for 2.6.35-r1.
* Pekka Enberg <[email protected]> wrote:
> On Tue, Jun 1, 2010 at 7:10 AM, <[email protected]> wrote:
> > On Tue, Jun 01, 2010 at 12:19:29AM +0100, Alex Buell wrote:
> >> http://www.phoronix.com/vr.php?view=14976
> >>
> >> Question: Why?
> >
> > One of the theories that has been advanced is that it's simply this
> > problem:
> >
> > ? ? ? ?http://lkml.org/lkml/2010/5/22/154
> >
> > If so, it points out how idiotic Phoronix is about not being able to
> > notice udev pegging the CPU at 100% being someone bad for its
> > benchmark runs. ?:-)
> >
> > OTOH, this bug has been known for over a week, and it is sort sad that
> > we haven't reverted this patch. ?It looks like the conversation has
> > died, but without a fix?
>
> It's fixed by 1eb2cbb6d5efe129 so the problem doesn't exist for 2.6.35-r1.
Btw., the changelog in 1eb2cbb6d5efe129:
| From 1eb2cbb6d5efe129cd006691267ce513c0aa59da Mon Sep 17 00:00:00 2001
| From: Al Viro <[email protected]>
| Date: Thu, 27 May 2010 11:11:06 -0400
| Subject: [PATCH] Revert "anon_inode: set S_IFREG on the anon_inode"
|
| This reverts commit a7cf4145bb86aaf85d4d4d29a69b50b688e2e49d.
| ---
| fs/anon_inodes.c | 2 +-
| 1 files changed, 1 insertions(+), 1 deletions(-)
Is lacking pretty much all essential pieces of information which are required
for reverts:
- it has no description about who reported the bug.
- it has no description about what the problem was and what the effects were.
People have little chance to link up the 'udev is spinning' bug to
this fix.
- it has no link back to '3836a03: anon_inodes: mark the anon inode private'
which introduced it and hence it has no -stable tag either.
- has no signoff line
Ingo
* Ingo Molnar <[email protected]> wrote:
> Is lacking pretty much all essential pieces of information which are
> required for reverts:
>
> - it has no description about who reported the bug.
In fact it was _bisected_ by Eric Paris, so a Bisected-by tag is a must.
Eric is a nice guy and i'm sure wont complain about this, but i can tell it
with a 100% certainty that to most testers and developers bisecting bugs is a
tiresome and error-prone process that involves quite a bit of work.
Bisecting a bug is often more work to do than the work which went into the
original commit and the revert, combined.
So if we want more people to test our commits then the least we can do is to
credit testers by making proper use of the Reported-by and Bisected-by tags.
Ingo
* [email protected] <[email protected]> wrote:
> On Tue, Jun 01, 2010 at 12:19:29AM +0100, Alex Buell wrote:
> > http://www.phoronix.com/vr.php?view=14976
> >
> > Question: Why?
>
> One of the theories that has been advanced is that it's simply this problem:
>
> http://lkml.org/lkml/2010/5/22/154
>
> If so, it points out how idiotic Phoronix is about not being able to notice
> udev pegging the CPU at 100% being someone bad for its benchmark runs. :-)
They might be 'minimally helpful' and they might want to maximize clicks, but
IMO that doesnt equate to 'idiotic', at all. The slowdown was real and they
have no obligation to figure out what caused it.
Think what an ordinary tester would do: install -rc1, see a slowdown, skip
back to v2.6.34. Reporting the 'macro performance' metrics is useful.
As Linux gets more and more mainstream we should get used to
selfish/hostile/unhelpful journalism, just like we had to get used to
selfish/hostile/unhelpful users, developers, etc. This isnt directed at Linux,
this is simply an unavoidable side effect of becoming more mainstream. And
there will be more of this, hopefully ;-)
Thanks,
Ingo
* Ingo Molnar <[email protected]> wrote:
> - it has no link back to '3836a03: anon_inodes: mark the anon inode private'
> which introduced it and hence it has no -stable tag either.
Ah, it got introduced by a7cf4145bb86 so no -stable relevancy.
Ingo
On Tue, Jun 01, 2010 at 08:00:39AM +0300, Pekka Enberg wrote:
> On Tue, Jun 1, 2010 at 7:10 AM, <[email protected]> wrote:
> > On Tue, Jun 01, 2010 at 12:19:29AM +0100, Alex Buell wrote:
> >> http://www.phoronix.com/vr.php?view=14976
> >>
> >> Question: Why?
> >
> > One of the theories that has been advanced is that it's simply this
> > problem:
> >
> > ? ? ? ?http://lkml.org/lkml/2010/5/22/154
> >
> > If so, it points out how idiotic Phoronix is about not being able to
> > notice udev pegging the CPU at 100% being someone bad for its
> > benchmark runs. ?:-)
> >
> > OTOH, this bug has been known for over a week, and it is sort sad that
> > we haven't reverted this patch. ?It looks like the conversation has
> > died, but without a fix?
>
> It's fixed by 1eb2cbb6d5efe129 so the problem doesn't exist for 2.6.35-r1.
When I first read this email, I thought it meant the test was done
on rc1, but reading the article:
To cut to the chase, between the 22nd and 24th of May there
looks to be at least one commit (though perhaps multiple based
upon the different data) within the Linus Torvalds 2.6 Git tree
that are negatively affecting many different server/desktop
benchmarks. We waited nearly a week to see if these regressions
would be organically caught and addressed, but they have not
been at least of the Linux 2.6 Git state as of 2010-05-26.
I'll give the udev fix a try w/the btrfs tests.
-chris