Port-amd64 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Is amd64 ready for the desktop?

David Laight <david%l8s.co.uk@localhost> writes:
>> No, that's not what it is. It is "Ulimits are set to prevent resource
>> starvation. Machines with more resources don't need the limits set so
>> low, but clearly clearly machines with fewer resources want the limits
>> lower, so perhaps it would be good to have the limits set based on
>> available resources instead of an arbitrary number picked for all
>> boxes of the same type whether they have 32M or 32G of memory."
> Actually you should assume that large machines are going to be running
> more programs and/or supporting more users.

You would think that, but I haven't seen evidence of it. Timesharing
ended long ago. The average number of people logging in to the average
box these days is order 1. There are exceptions (boxes at ISPs that do
hosting etc.), but they're run by people who are sophisticated enough
to do tuning if they need to.

Of course, there is an easy way to deal with the "dynamic load"
problem that it is real. You can have the system adjust limits based
on process load. It is still possible to have automatic policies that
generally work. One need not require that people hand tune all this
stuff for the average case.

> So the per process limits should be fixed for the machine type, and
> not, in any way, set based on the actual machine size.

I'm sorry, but this is ridiculous. My oldest 25MHz 486 with close to
no memory and a new x86 with gigs of memory are not even vaguely
similar in the sorts of tasks expected of them.

Now, one can continue going the way of Procrustes, and arbitrarily set
limits that are periodically adjusted by hand and are neither low
enough for the bottom end boxes nor high enough for the top end, or
one can accept that perhaps the expectations on a box with 4G of
memory and a 3MHz processor might be different.

> The current situation where some of the 'hard' limits are set to the
> kernel/system maximum values just lets non-privileged users lock the
> system solid.

So, if I understand correctly, you're suggesting that we leave things
as they are, but you're also suggesting that you don't like things as
they are.

Perry E. Metzger                perry%piermont.com@localhost

Home | Main Index | Thread Index | Old Index