Messages in this thread | | | From | kuznet@ms2 ... | Subject | Re: Bloat? (khttpd) | Date | Thu, 23 Dec 1999 19:41:01 +0300 (MSK) |
| |
Hello!
> Could you inform me what you are talking about?
Actually, I said: pushing back open requests on socket, got via hash table lookup.
Normally openrequests were born only under bh lock, and accepted under process lock. khttpd pushes back openrequests under user lock.
Another, but related, thing: khttpd grabs user lock on socket stolen from hash table. It breaks one of basic assumptions: backlogging does not occur, if socket is orphan.
> If there is an issue with > kHTTPd having a negative effect on other parts of the kernel, I would like > to know. (If I don't know about such things, I cannot solve them)
The first problem was mainly unsolvable inside khttpd. It is impossible to get bh lock in user process context. It is already solved (to 2.3.15) inside TCP, and solution is not so bad. Actually, later it even allowed to relax some constraints for backlog processing, so that the result is not purely negative 8).
The second flaw is more or less easy: if khttpd kept slave socket open, as all normal users do, rather than stole it from hash table, it would remove the problem.
Alexey
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |