Messages in this thread | | | Date | Tue, 16 Jun 2009 15:38:32 +0200 | From | Eric Dumazet <> | Subject | Re: [GIT]: Networking |
| |
David Miller a écrit : > From: Ingo Molnar <mingo@elte.hu> > Date: Tue, 16 Jun 2009 12:11:32 +0200 > >> sure, here you go (i also added a stack dump, just in case it's some >> kernel-internal socket open): >> >> [ifconfig:3516]: Creates X25 socket. >> >> so plain ifconfig. Part of the ~1.5 years old net-tools-1.60-84.fc8. > > Ok, ifconfig seems to open one of every socket type when it starts up. > That explains why an X25 socket is openned and then closed. > > Now the question is why is the X25 socket released by a timer? This > should only happen if some socket memory is still pending in the > socket buffers. > > Wait, I know why this is triggering now. It's Eric Dumazet's SKB > accounting optimizations. > > So, I'll fix the X25 timer bug. It's always been there, but > beforehand this deferred-via-timer x25 socket destruction path almost > never triggers. So we never saw it. Now it happens every time. > > Eric can you sniff around and see what you think about this unforseen > (at least for me) consequence of your changes? Socket layers that use > the current sk_wmem_alloc/sk_rmem_alloc value at destroy time to > determine if a socket can be killed immediately, or need to be killed > later via timer, will always see that dummy one byte allocation you > now put there. > > Can you look into that? > > Thanks.
Sure I can look if a layer uses sk_wmem_alloc as you describe.
(I take you refer to commit 2b85a34e911bf483c27cfdd124aeb1605145dc80 : net: No more expensive sock_hold()/sock_put() on each tx)
So there is no impact for sk_rmem_alloc AFAIK
Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |