login
Search
I'm afraid you will need to categorize me more as an innocent bystander than a kernel developer and, as such, I have an endusery x86 with 768M (but I Rather, it does not help if you are not swapping or idling. Probably largely due to me being a rather serial person I seem to never even push my git tree from cache. Hence my belief that "I don't have a pressing need for it". Taking a laptop as an example is interesting in itself by the way since a spundown disk (most applicable to laptops) is an argument against swap prefetch even when idle and when I'm not mistaken the feature actually After using and quiting OO.o. If you simply don't have any memory free to prefetch into swap prefetch won't help any. The fact that it helps the case Well, the trouble at least to some is that they indeed seem to be rather unrelated. Why does the updatedb run even cause swapout? (itself ofcourse a Actually, interactivity is largely about latency and latency is largely or partly independent of CPU speed -- if something's keeping the system from scheduling for too long it's likely that it's hogging the CPU for a fixed number of usecs and those pass in the same amount of time on all CPUs (we hope...). But that's a tangent anyway. I'm just glad that I get to say that I believe Personally I'd go for sexual favours directly (but then again, I always do). But please also note that I even _literally_ said above that I myself am not against swap-prefetch or anything and yet I get what appears to be an least somewhat adversary rant directed at me. Which in itself is fine, but not too helpful... Nick Piggin is the person to convince it seems and if I've read things right (I only stepped into this thing at the updatedb mention, so maybe I haven't) his main question is _why_ the hell it helps updatedb. As long as you don't know this, then even a solution that helps could be papering over a problem which you'd much rather fix at the root rather than at the ...
btw., i'd like to make this clear: if you want stuff to go upstream, do not concentrate on 'convincing the maintainer'. Instead concentrate on understanding the _problem_, concentrate on making sure that both you and the maintainer understands the problem correctly, possibly write some testcase that clearly exposes it, and help the maintainer debug the problem. _Optionally_, if you find joy in it, you are also free to write a proposed solution for that problem and submit it to the maintainer. But a "here is a solution, take it or leave it" approach, before having communicated the problem to the maintainer and before having debugged the problem is the wrong way around. It might still work out fine if the solution is correct (especially if the patch is small and obvious), but if there are any non-trivial tradeoffs involved, or if nontrivial amount of code is involved, you might see your patch at the end of a really long (and constantly growing) waiting list of patches. Ingo -
Hi Ingo, [ Going off-topic, nothing related to swap/prefetch/etc. Just getting a hang of how development goes on here ... ] This itself may require some "convincing" to do. What if the maintainer just doesn't recognize the problem? Note that the development model here is more about the "social" thing than purely a "technical" thing. People do handwave, possibly due to innocent misunderstandings, possibly without. Often it's just a case of seeing different reasons behind Oh yes -- that'll be helpful, but definitely not necessarily a prerequisite for all issues, and then you can't even expect everybody to write or test/benchmark with testcases. (oh, btw, this is assuming you do find Umm ... well. Should this "dance-with-the-maintainer" and all be really necessary? What you're saying is easy if a "bug" is simple and objective, with mathematically few (probably just one) possible correct solutions. Often (most often, in fact) it's a subjective issue -- could be about APIs, high level design, tradeoffs, even little implementation nits ... with one person wanting to do it one way, another thinks there's something hacky or "band-aidy" about it and a more beautiful/elegant solution exists elsewhere. Oh yes. But why "optionally"? This is *precisely* what the spirit of development in such open / distributed projects is ... unless Linux wants to die the same, slow, ivory-towered, miserable death that Umm, ok ... pretty unlikely Linus or Andrew would take patches for any kernel subsystem (that isn't obvious/trivial) from anybody just like that, so you do need to Cc: the ones they trust (maintainer) to ensure they Again, agreed -- but people can plausibly see different root causes for That's the whole point. For non-trivial / non-obvious / subjective issues, the "process" you laid out above could itself become a problem ... Satyam -
sure - but i was really not talking about from the user's perspective, but from the enterprising kernel developer's perspective who'd like to solve a particular problem. And the nice thing about concentrating on the problem: if you do that well, it does not really matter what the maintainer thinks! ( Talking to the maintainer can of course be of enormous help in the quest for understanding the problem and figuring out the best fix - the maintainer will most likely know more about the subject than yourself. More communication never hurts. It's an additional bonus if you manage to convince the maintainer to take up the matter for himself. It's not a given right though - a maintainer's main task is to judge code that is being submitted, to keep a subsystem running smoothly and to not let it regress - but otherwise there can easily be different priorities of what tasks to tackle first, and in that sense the maintainer is just one of the many overworked kernel developers who has no real obligation what to tackle first. ) If the maintainer rejects something despite it being well-reasoned, well-researched and robustly implemented with no tradeoffs and maintainance problems at all then it's a bad maintainer. (but from all i've seen in the past few years the VM maintainers do their job pretty damn fine.) And note that i _do_ disagree with them in this particular swap-prefetch case, but still, the non-merging of swap-prefetch was not a final decision at all. It was more of a "hm, dunno, i still dont really like it - shouldnt this be done differently? Could we debug this a bit better?" reaction. Yes, it can be frustrating after more than one no, but Con is/was certainly more than capable to write testcases and to debug various scenarios. That's the way how new maintainers are found within Linux: people take matters in their own hands and improve a subsystem so that they'll either peacefully co-work with the other maintainers or they ...
Hi, Some general thoughts about submitter/maintainer responsibilities, not necessarily connected with the recents events (I hasn't been following them closely - some people don't have that much free time to burn at their hands ;)... Yes, this is a really good strategy to get you changes upstream (and it works) - just make changes so perfect that nobody can really complain. :) The only problem is that the bigger the change becomes the less likely it is to get it perfect so for really big changes it is also useful to show maintainer that you take responsibility of your changes (by taking bugreports and potential review issues very seriously instead of ignoring them, past history of your merged changes has also a big influence here) so he will know that you won't leave him in the cold with your code when bugreports Yep, and patch author should try to help maintainer understand both the problem he is trying to fix and the solution, i.e. throwing some undocumented Heh, now that you've raised IDE saga I feel obligated to stand up and say a few words... The latest opening of IDE saga was quite interesting in the current context because we had exactly the reversed situation there - "independent" maintainer and "enterprise" developer (imagine the amount of frustration on both sides) but the root source was quite similar (inability to get changes merged). IMO the source root of the conflict lied in coming from different perspectives and having a bit different priorities (stabilising/cleaning current code vs adding new features on top of pile of crap). In such situations it is very important to be able to stop for a moment and look at the situation from the other person's perspective. In summary: The IDE-wars are the thing of the past and lets learn from IDE-world The idea of growing into the job and replacing the maintainer by proving the you are doing better job was viable few years ago but may not be feasible today. If maintainer is "enterprise" developer and ...
IMO... Tejun is an excellent counter-example. He showed up as an independent developer, put a bunch of his own spare time and energy into the codebase, and is probably libata's main engineer (in terms of code output) today. If I get hit by a bus tomorrow, I think the Linux I think Tejun is a counter-example here too :) Everyone's experience is different, but from my perspective, Tejun "appeared out of nowhere" producing good code, and so, it got merged rapidly. Personally, for merging code, I tend to trust people who are most in tune with "the Linux Way(tm)." It is hard to quantify, but quite often, Indeed... Jeff -
IMO this doesn't qualify as a counter-example here et all unless you are trying to say that Tejun does your job much better and that Tejun (like any of other developers) spent some time in-the-making and this time was in large part spent in the IDE-land, and yes I'm also very glad of the effects. :) Thanks, Bart -