> Hi,
>
> On Thu, 16 Sep 1999 22:54:45 -0700, Dan Kegel <dank@alumni.caltech.edu>
> said:
>
> > Alan recently said that each handle takes up 20k in kernel space.
> > so 100,000 connections could take up 100k*20k = 2GB of RAM,
> > which might cause some trouble except on very recent kernels
> > (and maybe you still need a patch for this).
Is that 20k all the time? What about when buffers are almost always empty?
What if the window in one or both directions is set to, say, 4k?
What is the minimum? What if the window was automatically set low, say 2k,
and automatically raised to some reasonable size (15k, 30k) based on the
largest continuous burst?
I really can't see how the kernel needs more than 2-4k without buffers and why
those can't be allocated dynamically. Of course I haven't tried to fully
grock the code yet. Enlightenment welcome, as always.
> There are no plans for a kernel on Intel which can address more than 2GB
> of system memory for the networking code. Memory above 1G or 2G
> (depending on the way the kernel has been compiled) is only usable for
> process's private virtual address spaces on the current BIGMEM kernels,
> and even if we extend that to allow high memory page cache access, we
> won't support network control blocks or buffers in high memory.
>
> > I'd be interested in hearing whether anyone has gone past
> > 64k handles opened; who knows, maybe some bad code somewhere is
> > using a short to hold an fd.
>
> I've had one file dup()ed a million times, and yes, we used to store
> that refcount in a short. Not any more. :)
Now that's interesting...
>
>
> --Stephen
sdw
-- OptimaLogic - Finding Optimal Solutions Web/Crypto/OO/Unix/Comm/Video/DBMS sdw@lig.net Stephen D. Williams Senior Consultant/Architect http://sdw.st 43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax 5Jan1999
- 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/