Messages in this thread | | | Date | Sun, 22 Mar 1998 14:55:07 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: bug in 2.1.89 include/net/sock.h? |
| |
On Sun, 22 Mar 1998, David S. Miller wrote: > > Ok. In this case I propose:
No, don't do it this way.
> 1) resource allocation charging is done the same as now > 2) a mechanism is added to tell sock_[rw]free() to not make > the "space available" wakeup callbacks, perhaps a sort > of skb_nowakeup() which sets state in the skb, after memory > and SOCK linkage has been made, which makes this happen > and we use this in TCP for ACK frames, and transmission clones
If ACK's etc frames take up resources, we _have_ to wake up, because otherwise we can have cases where we never wake up when the resources are free'd.
Please do NOT add any silly special cases for wakeup: either you shouldn't account for the ACK's per-socket, or you have to wake things up regardless of whether it is an ACK or a normal packet.
Doing a special "tcp_nowakeup()" thing is only digging yourself into a deeper hole and will be truly horrible to debug.
Note that regardless of whether the free'd frame was a ACK or a data frame, you don't actually have to wake up things unconditionally. Right now we are using the stupid approach that we _always_ wake up, but that is obviously bad regardless of whether the packet was an ACK or not.
Something like
/* Wake up only if we have more than half the wspace free: */ if (atomic_read(sk->wmem_alloc)*2 <= sk->sndbuf)) { ... wake_up() .. }
should get rid of some unnecessary wake-ups, whether they are due to ACK's or not. There's no point in having the writer trickle the write data in small chunks anyway.
> 3) we investigate wake up policies past these changes at some > later data, ie. research problem ;-)
Not together with 1+2 which would be a potentially endless source of hard-to-find bugs. David, I do _not_ want people to start adding more causes for bugs for no better reason that some fairly minor performance tweak that probably has other much better solutions anyway.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |