Hi, I think this thread has gone far, far off the rails. If you're able to provide some solid debugging or willing to put in the effort to provide said solid debugging, then great. The easier you can make it for someone to fix for you (whether they're a FreeBSD committer or otherwise) the more likely it'll be fixed. There's no-one notionally in charge and paid to look after the scheduler. This is the unfortunate truth. No amount of saying "but but people are paid to do this!" will fix that particular point. The way that 99% of FreeBSD work gets done is when someone (who is a committer or otherwise) gets angry at how something doesn't quite work for them, and they decide to go and do something about it. The only point where a committer needs be involved is when someone wants to push their code into "upstream" (to borrow a Linux-ism) FreeBSD. If you're able to setup KTR and drive it + schedgraph (just like Steve has) and run this on a workload that is _repeatedly_ broken for you, then you're immediately going to have a better chance at getting it fixed. Bonus points if you can run the same benchmark on 4BSD and ULE, reporting KTR + schedgraph traces for both. That is going to be _by far_ the most helpful thing anyone can do in this ridiculously overly-verbose thread. Come on guys/girls/fuzzy creatures, you want to fix the problem? Bitching about it won't help. Unless you're like me and have an interest in Linguistics and end up writing a "flame war to code" generator. Then we'll likely be fine. :) AdrianReceived on Fri Dec 23 2011 - 17:58:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:22 UTC