Andrew Morton wrote:
...in my earlier emails I asked a number of questions regarding whether existing facilities, queued patches or further slight kernel changes could provide a sufficient solution to these problems. The answer may well be "no". But diligence requires that we be able to prove that, and handwaving doesn't provide that proof, does it?
Hi Andrew, I missed those questions about queued patches. So far the closest we have seen to anything relevant is Evgeniy's proposed network sub-allocater, which just doesn't address the problem, as Peter and I have explained in some detail, and the dirty page throttling machinery which is obviously flawed in that it leaves a lot of room for corner cases that have to be handled with more special purpose logic. For example, what about kernel users that just go ahead and use lots of slab without getting involved in the dirty/mapped page accounting? I don't know, maybe you will handle that too, but then there will be another case that isn't handled, and so on. The dirty page throttling approach is just plain fragile by nature. We already know we need to do reserve accounting for struct bio, so what is the conceptual difficulty in extending that reasoning to struct sk_buff, which is very nearly the same kind of beastie, performing very nearly the same kind of function, and suffering very nearly the same kind of problems we had in the block layer before mingo's mempool machinery arrived? Did I miss some other queued patch that bears on this? And I am not sure what handwaving you are referring to. Note that we have not yet submitted this patch to the queue, just put it up for comment. This patch set is actually getting more elegant as various individual artists get their flames in. At some point it will acquire a before-and-after test case as well, then we can realistically compare it to the best of the alternate proposals. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html