[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload function.
On Thu, 2012-02-02 at 20:34 +0000, Eric Dumazet wrote: > Le jeudi 02 février 2012 à 19:59 +0000, Ian Campbell a écrit : > > On Thu, 2012-02-02 at 17:48 +0000, Eric Dumazet wrote: > > > Le jeudi 02 février 2012 à 17:28 +0000, Wei Liu a écrit : > > > > > > > You're right about this. > > > > > > > > But this part is destined to get wiped out (in the very near future?) -- > > > > see following patches. So I don't think it is worthy to fix this. > > > > > > > > > > Before adding new bugs, you must fix previous ones. > > > > I've never heard of this requirement before! It's a wonder anyone ever > > gets anything done. > > > > Anyway, I think it would be reasonable to just remove the kthread_bind > > call from this loop. We don't actually want/need a thread per online CPU > > in any strict sense, we just want there to be some number of worker > > threads available and ~numcpus at start of day is a good enough > > approximation for that number. There have been patches floating around > > in the past which make the number of groups a module parameter which > > would also be a reasonable thing to dig out if we weren't just about to > > remove all this code anyway. > > > > So removing the kthread_bind is good enough for the short term, and for > > stable if people feel that is necessary, and we can continue in mainline > > with the direction Wei's patches are taking us. > > > > That sounds a right fix. > > Why do think its not reasonable that I ask a bug fix ? I don't think it is at all unreasonable to ask for bug fixes but in this case Wei's series is removing the code in question (which would also undoubtedly fix the bug). As it happens the fix turns out to be simple but if it were complex I would perhaps have disagreed more strongly about spending effort fixing code that is removed 2 patches later, although obviously that would have depended on the specifics of the fix in that case. > Next time, dont bother send patches for review if you dont want > reviewers. The review which you are doing is certainly very much appreciated, I'm sorry if my disagreement over this one point gave/gives the impression that it is not. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |