On 2000-10-11 19:53:50 -0700, [EMAIL PROTECTED] wrote:
> On other machines I'd set RLIMIT_DATA and my OOM problems went away,
> but on linux this didn't work
RLIMIT_DATA appears to only be checked for aout format executables.
Looking at the 2.4.0-test10pre1 sources for fs/binfmt_aout.c and
On 2000-10-11 11:45:06 -0400, Bruce A. Locke wrote:
> This manpage shows me functions and structs.
What were you expecting from the system call section of the Linux
Programmer's Manual? Dancing girls?
(h...)
> I'm assuming you want these used by the offending program or the shell
> under
On 2000-10-11 12:48:54 -0400, Andrew Pimlott wrote:
> No way should a desktop user be responsible for micro-managing the
> resource usage of his applications.
That's right. The systems administrator should, and will set
appropriate limits for users on his/her system that apply from login.
This
On Thu, Oct 12, 2000 at 01:58:49AM +1100, Matthew Hawkins wrote:
> On 2000-10-11 10:33:39 -0400, Bruce A. Locke wrote:
> >
> > Your making the deadly assumption that all applications behave themselves
> > exactly the same all the time. Oops... netscape decided to freak out and
> > take up all
- Received message begins Here -
>
> On 2000-10-11 09:45:30 -0500, Jesse Pollard wrote:
> > Until user memory resource quotas are included in the kernel, there will be
> > nothing else that can be done. Even with resource quotas, if the total of
> > active users exceeds the
On Thu, 12 Oct 2000, Matthew Hawkins wrote:
>
> Seriously, am I missing something obvious or is it far simpler just to
> keel over and die if the system goes OOM? I mean, seriously, if the
> administrator lets it get to that state then he/she/it deserves a dead
> system. It's akin to having
On 2000-10-11 10:33:39 -0400, Bruce A. Locke wrote:
>
> Your making the deadly assumption that all applications behave themselves
> exactly the same all the time. Oops... netscape decided to freak out and
> take up all your memory... guess its the admins fault.
Yep, for not setting appropriate
On 2000-10-11 09:45:30 -0500, Jesse Pollard wrote:
> Until user memory resource quotas are included in the kernel, there will be
> nothing else that can be done. Even with resource quotas, if the total of
> active users exceeds the resource then the same/equivalent situation occurs.
So
- Received message begins Here -
>
>
> Heh.. now all we need is some smart-arse to make something similar to
> apply to the _entire_ VM subsystem, and both Rik and Andrea can be happy
> ;)
>
> Seriously, am I missing something obvious or is it far simpler just to
> keel over
Heh.. now all we need is some smart-arse to make something similar to
apply to the _entire_ VM subsystem, and both Rik and Andrea can be happy
;)
Seriously, am I missing something obvious or is it far simpler just to
keel over and die if the system goes OOM? I mean, seriously, if the
On Wed, Oct 11, 2000 at 11:08:41AM +0200, Helge Hafting wrote:
> Nothing wrong with a big init - the problem is a memory-leaking init.
> That one will die anyway, wether it dies early from an OOM-killer
> or later when all other processes are gone don't really matter.
Indeed.
Andrea
-
To
Andrea Arcangeli wrote:
>
> On Tue, Oct 10, 2000 at 09:06:49AM +0200, Helge Hafting wrote:
> > If you want init to live - prove that it don't eat too much memory.
>
> I don't see why the machine should be stable only if init is small.
> My kernel won't be stable only if init is small since it
Andrea Arcangeli wrote:
On Tue, Oct 10, 2000 at 09:06:49AM +0200, Helge Hafting wrote:
If you want init to live - prove that it don't eat too much memory.
I don't see why the machine should be stable only if init is small.
My kernel won't be stable only if init is small since it doesn't
On Wed, Oct 11, 2000 at 11:08:41AM +0200, Helge Hafting wrote:
Nothing wrong with a big init - the problem is a memory-leaking init.
That one will die anyway, wether it dies early from an OOM-killer
or later when all other processes are gone don't really matter.
Indeed.
Andrea
-
To
Heh.. now all we need is some smart-arse to make something similar to
apply to the _entire_ VM subsystem, and both Rik and Andrea can be happy
;)
Seriously, am I missing something obvious or is it far simpler just to
keel over and die if the system goes OOM? I mean, seriously, if the
Your making the deadly assumption that all applications behave themselves
exactly the same all the time. Oops... netscape decided to freak out and
take up all your memory... guess its the admins fault. Oops... some
mod_perl script decided to freak out and an apache process decides to suck
all
- Received message begins Here -
Heh.. now all we need is some smart-arse to make something similar to
apply to the _entire_ VM subsystem, and both Rik and Andrea can be happy
;)
Seriously, am I missing something obvious or is it far simpler just to
keel over and die
On 2000-10-11 09:45:30 -0500, Jesse Pollard wrote:
Until user memory resource quotas are included in the kernel, there will be
nothing else that can be done. Even with resource quotas, if the total of
active users exceeds the resource then the same/equivalent situation occurs.
So setrlimit()
On Wed, 11 Oct 2000, Bruce A. Locke wrote:
Your making the deadly assumption that all applications behave themselves
exactly the same all the time. Oops... netscape decided to freak out and
take up all your memory... guess its the admins fault. Oops... some
mod_perl script decided to
On 2000-10-11 10:33:39 -0400, Bruce A. Locke wrote:
Your making the deadly assumption that all applications behave themselves
exactly the same all the time. Oops... netscape decided to freak out and
take up all your memory... guess its the admins fault.
Yep, for not setting appropriate
On Thu, 12 Oct 2000, Matthew Hawkins wrote:
Seriously, am I missing something obvious or is it far simpler just to
keel over and die if the system goes OOM? I mean, seriously, if the
administrator lets it get to that state then he/she/it deserves a dead
system. It's akin to having your
- Received message begins Here -
On 2000-10-11 09:45:30 -0500, Jesse Pollard wrote:
Until user memory resource quotas are included in the kernel, there will be
nothing else that can be done. Even with resource quotas, if the total of
active users exceeds the resource
On Thu, 12 Oct 2000, Matthew Hawkins wrote:
Yep, for not setting appropriate resource limits.
man 2 setrlimit
Of course, if its a kernel bug that causes it I think you're SOL ;)
This manpage shows me functions and structs. I'm assuming you want these
used by the offending program or the
On Wed, 11 Oct 2000, Paul Jakma wrote:
that's why you have per process limits set. Eg, PAM makes this
exceedingly easy with pam_limit.so - edit /etc/security/limit.conf.
this prevents at least 90% of OOM situations (ie individual leaky
processes). eg netscape will then pop-up "can not
On Wed, 11 Oct 2000, Bruce A. Locke wrote:
I wasn't aware PAM settings affected daemons started up during boottime
but I will check into it, thank you.
daemons generally don't need to be PAM aware (unless they deal with
authorising things). The script that launches it however (if started
by
On Thu, Oct 12, 2000 at 01:58:49AM +1100, Matthew Hawkins wrote:
On 2000-10-11 10:33:39 -0400, Bruce A. Locke wrote:
Your making the deadly assumption that all applications behave themselves
exactly the same all the time. Oops... netscape decided to freak out and
take up all your
On Thu, 12 Oct 2000, Matthew Hawkins wrote:
On 2000-10-11 09:45:30 -0500, Jesse Pollard wrote:
Until user memory resource quotas are included in the kernel, there will be
nothing else that can be done. Even with resource quotas, if the total of
active users exceeds the resource then the
On 2000-10-11 12:48:54 -0400, Andrew Pimlott wrote:
No way should a desktop user be responsible for micro-managing the
resource usage of his applications.
That's right. The systems administrator should, and will set
appropriate limits for users on his/her system that apply from login.
This
On 2000-10-11 11:45:06 -0400, Bruce A. Locke wrote:
This manpage shows me functions and structs.
What were you expecting from the system call section of the Linux
Programmer's Manual? Dancing girls?
(h...)
I'm assuming you want these used by the offending program or the shell
under
I've had to support an app running as a back-end to a webserver that would
malloc() different amounts of memory depending on user input, up to
multiple gigabytes of memory which vastly exceeded the 512k the machine
had as main memory. The app was a program that would scan genetic
sequence
On 2000-10-11 19:53:50 -0700, [EMAIL PROTECTED] wrote:
On other machines I'd set RLIMIT_DATA and my OOM problems went away,
but on linux this didn't work
RLIMIT_DATA appears to only be checked for aout format executables.
Looking at the 2.4.0-test10pre1 sources for fs/binfmt_aout.c and
On Tue, Oct 10, 2000 at 05:58:46PM -0300, Rik van Riel wrote:
> On Tue, 10 Oct 2000, Tom Rini wrote:
> > On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote:
> > > On Tue, 10 Oct 2000, Ingo Oeser wrote:
> > >
> > > > before you argue endlessly about the "Right OOM Killer (TM)", I
> > >
On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote:
> On Tue, 10 Oct 2000, Ingo Oeser wrote:
>
> > before you argue endlessly about the "Right OOM Killer (TM)", I
> > did a small patch to allow replacing the OOM killer at runtime.
> >
> > So now you can stop arguing about the one and
Olaf Titz wrote:
>
> > > Still, it would be nice to recover that 4 MB when the system
> > > doesn't have any memory left.
> > Yup. The X server could give back the memory for some cases like the
> > background without too much hackery.
>
> Then Linux only needs to implement SIGDANGER, which has
On Tue, 10 Oct 2000, Rogier Wolff wrote:
>
> So if Netscape can "pump" 40 extra megabytes of memory out of X, this
> can be exploited.
>
> Now we're back to the point that a heuristic can never be right all
> the time..
I agree. In fact, we never left that.
Nothing is perfect.
In
On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote:
> > So now you can stop arguing about the one and only OOM killer,
> > implement it, provide it as module and get back to the important
> > stuff ;-)
>
> This is definately a cool toy for people who have doubts
> that my OOM killer
On Tue, Oct 10, 2000 at 12:30:51PM -0300, Rik van Riel wrote:
> Not killing init when we "should" definately prevents
> embedded systems from auto-rebooting when they should
> do so.
>
> (OTOH, I don't think embedded systems will run into
> this OOM issue too much)
but when they do, they're
On Tue, 10 Oct 2000, Philipp Rumpf wrote:
> On Tue, Oct 10, 2000 at 12:06:07PM -0300, Rik van Riel wrote:
> > On Tue, 10 Oct 2000, Philipp Rumpf wrote:
> > > > > The algorithm you posted on the list in this thread will kill
> > > > > init if on 4Mbyte machine without swap init is large 3 Mbytes
>
On Tue, Oct 10, 2000 at 12:06:07PM -0300, Rik van Riel wrote:
> On Tue, 10 Oct 2000, Philipp Rumpf wrote:
> > > > The algorithm you posted on the list in this thread will kill
> > > > init if on 4Mbyte machine without swap init is large 3 Mbytes
> > > > and you execute a task that grows over 1M.
On Tue, 10 Oct 2000, Philipp Rumpf wrote:
> > > The algorithm you posted on the list in this thread will kill
> > > init if on 4Mbyte machine without swap init is large 3 Mbytes
> > > and you execute a task that grows over 1M.
> >
> > This sounds suspiciously like the description of a DEAD
[OOM killer war]
Hi there,
before you argue endlessly about the "Right OOM Killer (TM)", I
did a small patch to allow replacing the OOM killer at runtime.
You can even use modules, if you are careful (see khttpd on how
to do this without refcouting).
So now you can stop arguing about the one
Linus Torvalds wrote:
> Basically, the only thing _I_ think X can do is to really say "oh, please
> don't count my memory, because everything I do I do for my clients, not
> for myself".
>
> THAT is my argument. Basically there is nothing we can reliably account.
>
> So we might as well fall
On Tue, Oct 10, 2000 at 09:06:49AM +0200, Helge Hafting wrote:
> If you want init to live - prove that it don't eat too much memory.
I don't see why the machine should be stable only if init is small.
My kernel won't be stable only if init is small since it doesn't cost
anything to handle
On Tue, Oct 10, 2000 at 04:38:02AM +0100, Philipp Rumpf wrote:
> Init should never die. If we get to do_exit in init we'll panic which is
> the right thing to do (reboot on critical systems).
If the page fault can fail with OOM on init, init will get a SIGSEGV while
running a signal handler
On Mon, 9 Oct 2000, Linus Torvalds wrote:
> On Mon, 9 Oct 2000, Rik van Riel wrote:
> >
> > > I'd prefer just X having a higher "mm nice level" or something.
> >
> > Which it has, because:
> >
> > 1) CAP_RAW_IO
> > 2) p->euid == 0
>
> Oh, I agree, but we might want to generalize this a bit so
--On 09 October 2000, 17:40 -0300 Rik van Riel <[EMAIL PROTECTED]>
wrote:
> On Mon, 9 Oct 2000, James Sutherland wrote:
>> On Mon, 9 Oct 2000, Ingo Molnar wrote:
>> > On Mon, 9 Oct 2000, Rik van Riel wrote:
>> >
>> > > > so dns helper is killed first, then netscape. (my idea might not
>> > > >
Andreas Dilger wrote:
> Having a SIGDANGER handler is good for 2 reasons:
> 1) Lets processes know when memory is short so they can free needless cache.
> 2) Mark process with a SIGDANGER handler as "more important" than those
>without. Most people won't care about this, but init, and X, and
Albert D. Cahalan wrote:
> X, and any other big friendly processes, could participate in
> memory balancing operations. X could be made to clean out a
> font cache when the kernel signals that memory is low. When
> the situation becomes serious, X could just mmap /dev/zero over
> top of the
On Mon, Oct 09, 2000 at 06:34:29PM -0300, Rik van Riel wrote:
> On Mon, 9 Oct 2000, Ingo Molnar wrote:
> > On Mon, 9 Oct 2000, Rik van Riel wrote:
> >
> > > Would this complexity /really/ be worth it for the twice-yearly OOM
> > > situation?
> >
> > the only reason i suggested this was the
> > Still, it would be nice to recover that 4 MB when the system
> > doesn't have any memory left.
> Yup. The X server could give back the memory for some cases like the
> background without too much hackery.
Then Linux only needs to implement SIGDANGER, which has been talked
about for years...
Andrea Arcangeli wrote:
>
> On Mon, Oct 09, 2000 at 08:42:26PM +0200, Ingo Molnar wrote:
> > ignoring the kill would just preserve those bugs artificially.
>
> If the oom killer kills a thing like init by mistake or init has a memleak
> you'll notice both problems regardless of having a magic
Andrea Arcangeli wrote:
On Mon, Oct 09, 2000 at 08:42:26PM +0200, Ingo Molnar wrote:
ignoring the kill would just preserve those bugs artificially.
If the oom killer kills a thing like init by mistake or init has a memleak
you'll notice both problems regardless of having a magic for init
Albert D. Cahalan wrote:
X, and any other big friendly processes, could participate in
memory balancing operations. X could be made to clean out a
font cache when the kernel signals that memory is low. When
the situation becomes serious, X could just mmap /dev/zero over
top of the background
Andreas Dilger wrote:
Having a SIGDANGER handler is good for 2 reasons:
1) Lets processes know when memory is short so they can free needless cache.
2) Mark process with a SIGDANGER handler as "more important" than those
without. Most people won't care about this, but init, and X, and
--On 09 October 2000, 17:40 -0300 Rik van Riel [EMAIL PROTECTED]
wrote:
On Mon, 9 Oct 2000, James Sutherland wrote:
On Mon, 9 Oct 2000, Ingo Molnar wrote:
On Mon, 9 Oct 2000, Rik van Riel wrote:
so dns helper is killed first, then netscape. (my idea might not
make sense though.)
On Mon, 9 Oct 2000, Linus Torvalds wrote:
On Mon, 9 Oct 2000, Rik van Riel wrote:
I'd prefer just X having a higher "mm nice level" or something.
Which it has, because:
1) CAP_RAW_IO
2) p-euid == 0
Oh, I agree, but we might want to generalize this a bit so that root could
On Tue, Oct 10, 2000 at 04:38:02AM +0100, Philipp Rumpf wrote:
Init should never die. If we get to do_exit in init we'll panic which is
the right thing to do (reboot on critical systems).
If the page fault can fail with OOM on init, init will get a SIGSEGV while
running a signal handler
On Tue, Oct 10, 2000 at 09:06:49AM +0200, Helge Hafting wrote:
If you want init to live - prove that it don't eat too much memory.
I don't see why the machine should be stable only if init is small.
My kernel won't be stable only if init is small since it doesn't cost
anything to handle
Linus Torvalds wrote:
Basically, the only thing _I_ think X can do is to really say "oh, please
don't count my memory, because everything I do I do for my clients, not
for myself".
THAT is my argument. Basically there is nothing we can reliably account.
So we might as well fall back on
On Tue, 10 Oct 2000, Philipp Rumpf wrote:
The algorithm you posted on the list in this thread will kill
init if on 4Mbyte machine without swap init is large 3 Mbytes
and you execute a task that grows over 1M.
This sounds suspiciously like the description of a DEAD system ;)
But
[OOM killer war]
Hi there,
before you argue endlessly about the "Right OOM Killer (TM)", I
did a small patch to allow replacing the OOM killer at runtime.
You can even use modules, if you are careful (see khttpd on how
to do this without refcouting).
So now you can stop arguing about the one
On Tue, 10 Oct 2000, Philipp Rumpf wrote:
On Tue, Oct 10, 2000 at 12:06:07PM -0300, Rik van Riel wrote:
On Tue, 10 Oct 2000, Philipp Rumpf wrote:
The algorithm you posted on the list in this thread will kill
init if on 4Mbyte machine without swap init is large 3 Mbytes
and you
On Tue, 10 Oct 2000, Ingo Oeser wrote:
before you argue endlessly about the "Right OOM Killer (TM)", I
did a small patch to allow replacing the OOM killer at runtime.
So now you can stop arguing about the one and only OOM killer,
implement it, provide it as module and get back to the
On Tue, Oct 10, 2000 at 12:30:51PM -0300, Rik van Riel wrote:
Not killing init when we "should" definately prevents
embedded systems from auto-rebooting when they should
do so.
(OTOH, I don't think embedded systems will run into
this OOM issue too much)
but when they do, they're hard to
On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote:
So now you can stop arguing about the one and only OOM killer,
implement it, provide it as module and get back to the important
stuff ;-)
This is definately a cool toy for people who have doubts
that my OOM killer will do the
On Tue, 10 Oct 2000, Rogier Wolff wrote:
So if Netscape can "pump" 40 extra megabytes of memory out of X, this
can be exploited.
Now we're back to the point that a heuristic can never be right all
the time..
I agree. In fact, we never left that.
Nothing is perfect.
In fact, a
Olaf Titz wrote:
Still, it would be nice to recover that 4 MB when the system
doesn't have any memory left.
Yup. The X server could give back the memory for some cases like the
background without too much hackery.
Then Linux only needs to implement SIGDANGER, which has been talked
On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote:
On Tue, 10 Oct 2000, Ingo Oeser wrote:
before you argue endlessly about the "Right OOM Killer (TM)", I
did a small patch to allow replacing the OOM killer at runtime.
So now you can stop arguing about the one and only OOM
On Tue, 10 Oct 2000, Tom Rini wrote:
On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote:
On Tue, 10 Oct 2000, Ingo Oeser wrote:
before you argue endlessly about the "Right OOM Killer (TM)", I
did a small patch to allow replacing the OOM killer at runtime.
So now you
On Tue, Oct 10, 2000 at 05:58:46PM -0300, Rik van Riel wrote:
On Tue, 10 Oct 2000, Tom Rini wrote:
On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote:
On Tue, 10 Oct 2000, Ingo Oeser wrote:
before you argue endlessly about the "Right OOM Killer (TM)", I
did a small
Andreas Dilger wrote:
> Albert D. Cahalan wrote:
> > X, and any other big friendly processes, could participate in
> > memory balancing operations. X could be made to clean out a
>
> Gerrit Huizenga wrote:
> > Anyway, there is/was an API in PTX to say (either from in-kernel or through
> > some
> Rik van Riel wrote:
> > > How about SIGTERM a bit before SIGKILL then re-evaluate the OOM
> > > N usecs later?
> >
> > And run the risk of having to kill /another/ process as well ?
> >
> > I really don't know if that would be a wise thing to do
> > (but feel free to do some tests to see if
> If init dies the kernel hangs solid anyway
Init should never die. If we get to do_exit in init we'll panic which is
the right thing to do (reboot on critical systems).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
> (but I'd be curious if somebody actually manages to
> trick the OOM killer into killing init ... please
> test a bit more to see if this really happens ;))
In a non-real-world situation, yes. (mem=3500k, many drivers, init=/bin/bash,
tried to enter a command). Since the process in question
"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:
> Date: Mon, 9 Oct 2000 19:13:25 -0400 (EDT)
>
> >> From: Linus Torvalds <[EMAIL PROTECTED]>
>
> >> One of the biggest bitmaps is the background bitmap. So you have a
> >> client that uploads it to X and then goes away. There's nobody to
> >>
On Mon, Oct 09, 2000 at 04:07:32PM -0300, Rik van Riel wrote:
> > If the oom killer kills a thing like init by mistake
> That only happens in the "random" OOM killer 2.2 has ...
[OOM killer war]
Hi there,
before you argue endlessly about the "Right OOM Killer (TM)", I
did a small patch to
On Mon, 9 Oct 2000, Albert D. Cahalan wrote:
> Jim Gettys writes:
> >> From: Linus Torvalds <[EMAIL PROTECTED]>
>
> >> One of the biggest bitmaps is the background bitmap. So you have a
> >> client that uploads it to X and then goes away. There's nobody to
> >> un-count to by the time X decides
Jim Gettys writes:
>> From: Linus Torvalds <[EMAIL PROTECTED]>
>> One of the biggest bitmaps is the background bitmap. So you have a
>> client that uploads it to X and then goes away. There's nobody to
>> un-count to by the time X decides to switch to another background.
>
> Actually, the big
On Tue, 10 Oct 2000, bert hubert wrote:
> On Mon, Oct 09, 2000 at 02:38:10PM -0700, Linus Torvalds wrote:
>
> > So the process that gave X the bitmap dies. What now? Are we going to
> > depend on X un-counting the resources?
> >
> > I'd prefer just X having a higher "mm nice level" or
On Mon, 9 Oct 2000, Byron Stanoszek wrote:
> On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:
>
> > Anyway, there is/was an API in PTX to say (either from in-kernel or through
> > some user machinations) "I Am a System Process". Turns on a bit in the
> > proc struct (task struct) that made it exempt
On Mon, Oct 09, 2000 at 02:38:10PM -0700, Linus Torvalds wrote:
> So the process that gave X the bitmap dies. What now? Are we going to
> depend on X un-counting the resources?
>
> I'd prefer just X having a higher "mm nice level" or something.
I wonder how many megabytes we can fill with all
On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:
> Anyway, there is/was an API in PTX to say (either from in-kernel or through
> some user machinations) "I Am a System Process". Turns on a bit in the
> proc struct (task struct) that made it exempt from death from a variety
> of sources, e.g. OOM,
At Sequent, we found that there are a small set of processes which are
"critical" to the system's operation in that they should not be killed
on swap shortage, memory shortage, etc. This included things like init,
potentially inetd, the swapper, page daemon, clusters heartbeat daemon,
and
i <[EMAIL PROTECTED]>,
> Rik van Riel <[EMAIL PROTECTED]>,
> Byron Stanoszek <[EMAIL PROTECTED]>,
> MM mailing list <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler
> -
> On
On Mon, 9 Oct 2000, Aaron Sethman wrote:
> I think the run time should probably be accounted into to this
> as well. Basically start knocking off recent processes first,
> which are likely to be childless, and start working your way up
> in age.
I'm almost getting USENET flashbacks ... ;)
> > across AF_UNIX sockets so the mechanism is notionally there to provide the
> > credentials to X, just not to use them
>
> The problem is that there is no way to keep track of them afterwards.
If you use mmap for your allocator then beancounter will get it right. Every
resource knows which
On Mon, 9 Oct 2000, James Sutherland wrote:
> On Mon, 9 Oct 2000, Ingo Molnar wrote:
>
> > On Mon, 9 Oct 2000, Rik van Riel wrote:
> >
> > > > so dns helper is killed first, then netscape. (my idea might not
> > > > make sense though.)
> > >
> > > It makes some sense, but I don't think OOM is
On Mon, 9 Oct 2000, Jim Gettys wrote:
>
>
> On Date: Mon, 9 Oct 2000 14:38:10 -0700 (PDT), Linus Torvalds
><[EMAIL PROTECTED]>
> said:
>
> >
> > The problem is that there is no way to keep track of them afterwards.
> >
> > So the process that gave X the bitmap dies. What now? Are we going
On Date: Mon, 9 Oct 2000 14:38:10 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]>
said:
>
> The problem is that there is no way to keep track of them afterwards.
>
> So the process that gave X the bitmap dies. What now? Are we going to
> depend on X un-counting the resources?
>
X has to
On Mon, 9 Oct 2000, Rik van Riel wrote:
>
> > I'd prefer just X having a higher "mm nice level" or something.
>
> Which it has, because:
>
> 1) CAP_RAW_IO
> 2) p->euid == 0
Oh, I agree, but we might want to generalize this a bit so that root could
say "this process is important" and then
> > Sounds like one needs in addition some mechanism for servers to "charge"
> clients for
> > consumption. X certainly knows on behalf of which connection resources
> > are created; the OS could then transfer this back to the appropriate client
> > (at least when on machine).
>
> Definitely -
On Mon, 9 Oct 2000, Linus Torvalds wrote:
> On Mon, 9 Oct 2000, Alan Cox wrote:
> > > consumption. X certainly knows on behalf of which connection resources
> > > are created; the OS could then transfer this back to the appropriate client
> > > (at least when on machine).
> >
> > Definitely -
On Mon, 9 Oct 2000, Alan Cox wrote:
> > consumption. X certainly knows on behalf of which connection resources
> > are created; the OS could then transfer this back to the appropriate client
> > (at least when on machine).
>
> Definitely - and this is present in some non Unix OS's. We do pass
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> On Mon, 9 Oct 2000, Rik van Riel wrote:
>
> > Would this complexity /really/ be worth it for the twice-yearly OOM
> > situation?
>
> the only reason i suggested this was the init=/bin/bash, 4MB
> RAM, no swap emergency-bootup case. We must not kill init
On Mon, Oct 09, 2000 at 10:28:38PM +0100, Alan Cox wrote:
> > Sounds like one needs in addition some mechanism for servers to "charge" clients
>for
> > consumption. X certainly knows on behalf of which connection resources
> > are created; the OS could then transfer this back to the appropriate
On Mon, 9 Oct 2000, David Ford wrote:
> Not if "init" is a particular program running on a router floppy for
> example. The system may be designed to be a router and the userland
> monitor/control program is the only thing that runs and consumes 90% of the
> memory. If a forked or spawned
On Mon, 9 Oct 2000, Rik van Riel wrote:
> Would this complexity /really/ be worth it for the twice-yearly OOM
> situation?
the only reason i suggested this was the init=/bin/bash, 4MB RAM, no swap
emergency-bootup case. We must not kill init in that case - if the current
code doesnt then great
> Sounds like one needs in addition some mechanism for servers to "charge" clients for
> consumption. X certainly knows on behalf of which connection resources
> are created; the OS could then transfer this back to the appropriate client
> (at least when on machine).
Definitely - and this is
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> On Mon, 9 Oct 2000, Alan Cox wrote:
>
> > Lets kill a 6 week long typical background compute job because
> > netscape exploded (and yes netscape has a child process)
>
> in the paragraph you didnt quote i pointed this out and
> suggested adding all
rea Arcangeli <[EMAIL PROTECTED]>,
> Rik van Riel <[EMAIL PROTECTED]>,
> Byron Stanoszek <[EMAIL PROTECTED]>,
> MM mailing list <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler
>
1 - 100 of 229 matches
Mail list logo
