lkml.org 
[lkml]   [2000]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Some questions about linux kernel.
On Tue, 21 Mar 2000, Jesse Pollard wrote:
>David Whysong <dwhysong@physics.ucsb.edu>:

>> Not necessarrily. Here is the (rough) idea:
>>
>> 1. Modify Rik van Riel's patch to understand multiple "nice" levels.
>> 2. Have a daemon that finds new processes and renices them,
>> based on a config file. This puts policy in user-space.
>>
>> In theory, the daemon could be woken up by the kernel when new processes
>> are started, and renice them before they actually run.
>
>And what happens with SMP - the daemon may run on one CPU, the fork was
>done on the other.

Why would this be a problem? I can renice jobs all the time on my home
system, which is a dual Celeron. And it isn't critical that the daemon
sets a priority before the newly spawned process runs.

>> The beauty of this is that the daemon is not required for OOM handling;
>> Rik van Riel's kernel patch takes care of that. The daemon simply allows
>> policy to be placed in user-space.
>
>So the patch must pick the lowest priority proces to kill?

Something like that. It may be worth adding a new task priority field to
the task_struct. For now I'm just thinking about "nice" values though.

>> >The kernel can enforce the limit, but it cannot determine what the limit
>> >should be. This is the place for the userspace daemon.
>>
>> Ideally you want policy set in userspace, but executed by the kernel (with
>> a reasonable default case). That's what I'm trying to do, though not with
>> limits.
>
>Then there won't be any enfocement.

Come again? The kernel patch is the enfocement. It kills tasks when the
system runs out of virtual memory, using policies set by the daemon.

>> Refusing user login is yet another failure mode that will cause great
>> moaning and mayhem, and result in an out of work sysadmin. No thanks.
>
>Much less moaning that having the system crash when the user does login.
>Been there, done that.

If the system crashes, fix the problem, don't cover it up.

>> >It is a way to prevent OOM from occuring at the system level.
>>
>> Maybe, but I'm not convinced. You still have to deal with kernel
>> allocations. And these memory quotas come at huge expense, if they are to
>> be useful at preventing system-wide OOM.
>
>What huge expence? We are talking about decrementing a quota counter.
>Disk space is cheap. Quotas can even be used in an overcommitted form.

You're talking about preventing system-wide OOM using quotas. The ONLY way
to do that is to limit N users to 1/N of the system memory on average,
which effectively disables overcommit as a side effect.

>> What is needed is sane handling of system wide OOM situations. Killing the
>> offending process when the system runs OOM is a lot more sane than
>> crippling everybody's access to memory resources. IMNSHO.
>
>And the problem still causes system failures. The system is still blamed
>for being buggy. There is no need for either.

If you have a fixed amount of hardware resources, an overcommitting system
with the OOM killer patch should always survive low memory situations.
User processes will be killed, but you would have done that much earlier
in a quota'd system.

>Using a daemon to try to prevent OOM is very klugy, and won't work
>reliably.

You're not paying attention! The daemon doesn't handle OOM, that's what
the kernel patch does. The daemon just sets policy.

>And the problem still remains of properly identifying who, when and where
>the process is that causes the OOM. The system doesn't have the resources
>at the time it fails. Being able to say "kill x" is a way to get something
>done, but if x is the important process - you fail.

That's the motive for the userspace priority-setting daemon. The
daemon/OOM killer setup is actually far more flexible than memory quotas.
In fact, a form of memory quotas could be implemented with the daemon,
though you'd still need the kernel patch to handle extreme cases like a
fork bomb.

>If you make exceptions - never kill x, it is too important - then when x
>causes the failure, you are down.

Which can always be the case, since X directly accesses hareware. And this
is the reason for priorities; if the sysadmin sets a fork bomb to have
high priority, he gets what he deserves. Root is allowed to kill the
system.

Dave

David Whysong dwhysong@physics.ucsb.edu
Astrophysics graduate student University of California, Santa Barbara
My public PGP keys are on my web page - http://www.physics.ucsb.edu/~dwhysong
DSS PGP Key 0x903F5BD6 : FE78 91FE 4508 106F 7C88 1706 B792 6995 903F 5BD6
D-H PGP key 0x5DAB0F91 : BC33 0F36 FCCD E72C 441F 663A 72ED 7FB7 5DAB 0F91


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.085 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site