On Wed, August 9, 2006 21:45, Peter Zijlstra said: > On Wed, 2006-08-09 at 20:34 +0200, Indan Zupancic wrote: >> Why is it needed for the protocol specific code to call dev_unreserve_skb? > > It uses this to get an indication of memory pressure; if we have > memalloc'ed skbs memory pressure must be high, hence we must drop all > non critical packets. But you are right in that this is a problematic > area; the mapping from skb to device is non trivial. > > Your suggestion of testing skb->memalloc might work just as good; indeed > if we have regressed into the fallback allocator we know we have > pressure.
You seem to have explained dev_reserve_used usage, not the dev_unreserve_skb calls. But I've just found -v2 and see that they're gone now, great. -v2 looks much better. >> Only problem is if the device can change. rx_reserve_used should probably >> be updated when that happens, as a skb can't use reserved memory on a device >> it was moved away from. (right?) > > Well yes, this is a problem, only today have I understood how volatile > the mapping actually is. I think you are right in that transferring the > accounting from the old to the new device is correct solution. > > However this brings us the problem of limiting the fallback allocator; > currently this is done in __netdev_alloc_skb where rx_reserve_used it > compared against rx_reserve. If we transfer accounting away this will > not work anymore. I'll have to think about this case, perhaps we already > have a problem here. The point of the reservations is to avoid deadlocks, and they're always big enough to hold all in-flight skbs, right? So what about solving the whole device problem by using a global counter and limit instead of per device? The question is whether traffic on one device can starve traffic on other devices or not, and how big a problem that is. It probably can, tricky stuff. Though getting rid of the per device stuff would simplify a lot... >> > Also, I've been thinking (more pain), should I not up the reserve for >> > each SOCK_MEMALLOC socket. >> >> Up rx_reserve_used or the total ammount of reserved memory? Probably 'no' for >> both though, as it's either device specific or skb dependent. > > I came up with yes, if for each socket you gain a request queue, the > number of in-flight pages is proportional to the number of sockets. Yes, seems so. Good night, Indan - 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
