Some Of The Workloads Still Seeing Lower Performance On Linux 5.5 Git

[birdie]

That's bullshit. You have the same problems with closed source. The kind of development model doesn't impact software bugs here.

Not to the same extent 'cause businesses have jobs, money and reputation to lose.

[PuckPoltergeist]

Not to the same extent 'cause businesses have jobs, money and reputation to lose.

And if your business is Open Source, you have the same problems. Regressions happen, regardless if the development model is closed or open source. And you have to deal with this problems.

[Michael]

If the PTS is capable of bisecting these issues using graphs and what not, why not get it to submit the bug report automatically directly to bugzilla

I know the Gentoo tinderbox used to submit bug reports to the Gentoo bugzilla so I know this automation is possible

Because I only have so much time in a day and higher priority tasks to take care of and new content... A Bugzilla reporting plug-in could be added if there is a commercial customer interested but otherwise would take much time investigating the Bugzilla API, etc, with no gain/use in return.

[aufkrawall]

Perhaps also test against other distributions' kernel config? Not that the results turn out to be just more distribution specific shenanigans, caused by nightmarish software called apparmor or selinux.

[FireBurn]

Because I only have so much time in a day and higher priority tasks to take care of and new content... A Bugzilla reporting plug-in could be added if there is a commercial customer interested but otherwise would take much time investigating the Bugzilla API, etc, with no gain/use in return.

No gain/use in return? You constantly say how easy it is to find regressions using the PTS, yet whenever you uncover one you make it sound like a big deal to actually submit a bug report to get it fixed

I realise writing articles makes you money, but reporting bugs - especially ones that are affecting yourself - pays off when they're fixed!

The most infuriating thing is bisecting is the time consuming hard part, submitting what you've found is the _easy_ part, it makes sure that the right people are notified and can start working on a fix or revert

[loganj]

FireBurn @others he has to make a living. plus he's not really affected by the bug. he has material to write about regardless of kernel status. i say he's doing a great job already. you have seen the bug already so why don't you do your own test and file a bug report? he's only one person. maybe more can do the test and see for themselves how that appblabla (i'm lazy to look for the name) change the performance. the phoronix test suit it out there. just give it a try and then you can report the issue.

[Zoll]

No gain/use in return? You constantly say how easy it is to find regressions using the PTS, yet whenever you uncover one you make it sound like a big deal to actually submit a bug report to get it fixed

I realise writing articles makes you money, but reporting bugs - especially ones that are affecting yourself - pays off when they're fixed!

The most infuriating thing is bisecting is the time consuming hard part, submitting what you've found is the _easy_ part, it makes sure that the right people are notified and can start working on a fix or revert

Perhaps then when Michael finds the problematic commit, you can go ahead and submit the relevant bug report? how about that? This is all about community effort, why do you expect him to do everything for you?

[PuckPoltergeist]

Perhaps then when Michael finds the problematic commit, you can go ahead and submit the relevant bug report? how about that? This is all about community effort, why do you expect him to do everything for you?

Playing proxy isn't a good idea ever. This leads to more problems and time wasted instead of fixing bugs.

[MadCatX]

Michael Larabel, saving what could have been yet another disaster. Have a PayPal tip!

[kozman]

Michael Larabel, saving what could have been yet another disaster. Have a PayPal tip!

+1 I dropped Michael a Paypal tip for this article and I'm not even a Linux user much. He's one guy with limited time. Better to find who owns that commit and point them to the article(s). Let them do the hard work. LKML isn't always the best place since SO much traffic comes through there it's likely to get lost. Being that RC4 is out as of yesterday, there might be time to get a revert or fix in time for final 5.5. Rather than waiting for Michael, report it to the commiter yourself. If a whole slew of folks report it, it'll likely get the attention of the commiters and approvers.

Just Googling those commits shows

1) apparmor: reduce rcu_read_lock scope for aa_file_perm mediation Now that the buffers allocation has changed and no longer needs the full mediation under an rcu_read_lock, reduce the rcu_read_lock scope to only where it is necessary. Fixes: df323337e507 ("apparmor: Use a memory pool instead per-CPU caches") Signed-off-by: John Johansen <[email protected]>

and

2) apparmor: make it so work buffers can be allocated from atomic context In some situations AppArmor needs to be able to use its work buffers from atomic context. Add the ability to specify when in atomic context and hold a set of work buffers in reserve for atomic context to reduce the chance that a large work buffer allocation will need to be done. Fixes: df323337e507 ("apparmor: Use a memory pool instead per-CPU caches") Signed-off-by: John Johansen <[email protected]>

Maybe pointing John Johansen to these article will get some traction since Canonical has a LOT at stake from a well working 5,5 kernel. =)