From: John Heffner <[EMAIL PROTECTED]>
Date: Wed, 22 Mar 2006 23:38:25 -0500
> Given the relatively widespread availability of 100 Mbps or greater
> connectivity on college campuses and larger companies, and the increasing
> availability of fiber to the home (especially in places like S. Korea and
> Japan), I'd really like to see the default buffer sizes increased
> significantly. I'm thinking something like 4 MB would be a good number.
> (This number should probably be automatically chosen at boot time, so that
> it's not more than ~1-2% of total system memory.) This would give 100 Mbps on
> a transcontinental link, but isn't an unreasonable amount of memory for most
> systems.
I thought the current settings were good enough for a 100Mbps
transcontinental link? Or am I thinking 10Mbps?
Increasing these limits so much is not a good idea, all I need to do
is find a host which is willing to not sink any further TCP data I
send to it at the point in time I tell it to, and I can thus ramp up
the congestion window enough then consume 4MB of unswappable kernel
memory times the number of sockets I can open up. Not good.
And increasing the per-socket limit make it easier for a malicious user
to take a large portion away from the global TCP memory pool, and thus
put everyone into contrained memory allocation mode. Also not good.
Responsibly allowing applications to chew up large amounts of global
resources requires being able to take those resources away. With
virtual memory, we can swap the dirty pages out to disk, but with a
TCP sender something external controls whether we can liberate the
data or not. This is why we must use sane per-socket limits in order
to prevent dangerous situations like the one's above.
I do agree that the values should scale with the amount of memory.
And that we do right now, but it could definitely be better. All
3 array entries in each of tcp_{,r,w}mem[] should be expressed as
a percentage of main memory, and tcp_init() should just init them
up by applying those percentages to num_physpages.
The key point is to keep the per-socket limits far enough away from
the global pool limits such that it is not easy for a single entity
to maliciously put the allocator into conservative mode and penalize
the legitimate users.
What do you think?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
