> Never said it worked on a 32bit system. I was pointing out that there can beAh your point was that people might do this on 64bit systems? They could indeed. It would not be very efficient but it should work in theory at least with enough memory. Of course they don't need 4k stacks for it. They can also try it on 32bit and it will work to some extent too, just not scale very far. And 4k stack more or less won't make much difference for that because the stack is only a small part of the lowmem needed for a blocked thread with open sockets. But this thread clearly was about 32bit systems only. Note I didn't come up with that number, it was quoted to me earlier (but one of its authors has distanced itself from it now, so it seems to becoming more and more irrelevant indeed now) Stupid in this case just refers to the general observation that it is quite inefficient to do one thread per request on servers who are expected to process lots of long running connections. Perhaps I could have put that better I will give you that. Please assume I always meant "inefficient" when I wrote "stupid". Now that is a very doubtful claim. You realize that a functional network server thread needs a lot more lowmem than just the stack? -Andi --
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Andrew Morton | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
| Greg KH | Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Arjan van de Ven | Re: [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Jarek Poplawski | Re: [BUG] New Kernel Bugs |
