This patch fixes a bug in oom_kill. The way it was written, the OOM killer
would try to kill the idle task if the task selected immediately before it
had the most "badness". Probably because of the order of for_each_task(),
this wouldn't ever happen, but I don't think we want to depend on that.
> > Good, so the OOM killer works.
>
> But it doesn't work for this kind of application misbehaviours (or
> user attacks):
>
> main() { while(1) if (fork()) malloc(1); }
This seems to be a fork() bomb, not a VM issue. The system is overwhelmed by
the the forks, not by the space consumed by the
Good, so the OOM killer works.
But it doesn't work for this kind of application misbehaviours (or
user attacks):
main() { while(1) if (fork()) malloc(1); }
This seems to be a fork() bomb, not a VM issue. The system is overwhelmed by
the the forks, not by the space consumed by the
This patch fixes a bug in oom_kill. The way it was written, the OOM killer
would try to kill the idle task if the task selected immediately before it
had the most "badness". Probably because of the order of for_each_task(),
this wouldn't ever happen, but I don't think we want to depend on that.
Here's an updated version of the "oom_nice" patch. It allows a sysadmin to
set the "oom niceness" for processes, either by PID or by process name. The
oom niceness value factors into the badness() function called by Rik's
OOM killer. Negative values decrease the chance that the process will be
Here's an updated version of the "oom_nice" patch. It allows a sysadmin to
set the "oom niceness" for processes, either by PID or by process name. The
oom niceness value factors into the badness() function called by Rik's
OOM killer. Negative values decrease the chance that the process will be
Is it possible to get a process's name / full execution path (from
kernelspace) given only a task struct? I can't find any pointers to this
information in the task struct, and I don't know where else it might be. ps
seems to be able to get the process name, but that's from userspace.
Apologies in
Is it possible to get a process's name / full execution path (from
kernelspace) given only a task struct? I can't find any pointers to this
information in the task struct, and I don't know where else it might be. ps
seems to be able to get the process name, but that's from userspace.
Apologies in
Here's a small patch to allow a user to protect certain PIDs from death-
by-OOM-killer. It uses the proc entry '/proc/sys/vm/oom_protect'; echo the
PIDs to be protected:
echo 1 516 > /proc/sys/vm/oom_protect
The idea is that sysadmins can mark some daemon processes as off-limits for
the OOM
Here's a small patch to allow a user to protect certain PIDs from death-
by-OOM-killer. It uses the proc entry '/proc/sys/vm/oom_protect'; echo the
PIDs to be protected:
echo 1 516 /proc/sys/vm/oom_protect
The idea is that sysadmins can mark some daemon processes as off-limits for
the OOM
I understand that the headers in /usr/include/linux shouldn't be overwritten
by new kernel installs. But can someone elaborate on Linus's original
admonition
(http://kernelnotes.org/lnxlists/linux-kernel/lk_0007_04/msg00881.html)? Am
I never, ever, ever allowed to update my system headers for the
I understand that the headers in /usr/include/linux shouldn't be overwritten
by new kernel installs. But can someone elaborate on Linus's original
admonition
(http://kernelnotes.org/lnxlists/linux-kernel/lk_0007_04/msg00881.html)? Am
I never, ever, ever allowed to update my system headers for the
> It doesn't practically matter how efficient the X server is when
> you aren't busy, after all.
A simple polling scheme (i.e. not using poll() or select(), just looping
through all fd's trying nonblocking reads) is perfectly efficient when the
server is 100% busy, and perfectly inefficient when
It doesn't practically matter how efficient the X server is when
you aren't busy, after all.
A simple polling scheme (i.e. not using poll() or select(), just looping
through all fd's trying nonblocking reads) is perfectly efficient when the
server is 100% busy, and perfectly inefficient when
1. Does Linux use call gates (as specified in the Intel SDK vol.3) when a
user process makes a system call? From what I understand, call-gates let a
ring-3 process execute ring-0 code, which sounds exactly like a system call.
I've found all of the actual system call functions (sys_ni etc.) in
1. Does Linux use call gates (as specified in the Intel SDK vol.3) when a
user process makes a system call? From what I understand, call-gates let a
ring-3 process execute ring-0 code, which sounds exactly like a system call.
I've found all of the actual system call functions (sys_ni etc.) in
> no, x86 virtual memory is 32 bits - segmentation only provides a way to
> segment this 4GB virtual memory, but cannot extend it. Under Linux there
> is 3GB virtual memory available to user-space processes.
>
> this 3GB virtual memory does not have to be mapped to the same physical
> pages all
Ok, I should have thought of that ;-). I've never used modprobe directly
myself, and had forgotten that was possible. Thanks to everyone who replied.
chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ
Why is modprobe kept as a separate executable, when nothing else in the
kernel is (seems to be)? What is the advantage to keeping modprobe separate,
instead of statically linked into the kernel? Are users able to replace
modprobe with a better version? If so, why not do the same thing with other
Ok, I should have thought of that ;-). I've never used modprobe directly
myself, and had forgotten that was possible. Thanks to everyone who replied.
chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ
> > Am I reading this correctly--the address of the main() function for a
> > process is guaranteed to be the lowest possible virtual address?
> >
> > chris
> >
>
> It is one of the lowest. The 'C' runtime library puts section
> .text (the code) first, then .data, then .bss, then .stack. The
>
> On Wed, 11 Oct 2000 18:10:40 -0400,
> [EMAIL PROTECTED] wrote:
> >Are you sure it was compiled with the correct CPU? If you configure the
> >CPU incorrectly (686 when you only have a 586, etc.) the kernel *will*
> >refuse to boot.
> >
> >Maybe we should have the kernel print the CPU
On Wed, 11 Oct 2000 18:10:40 -0400,
[EMAIL PROTECTED] wrote:
Are you sure it was compiled with the correct CPU? If you configure the
CPU incorrectly (686 when you only have a 586, etc.) the kernel *will*
refuse to boot.
Maybe we should have the kernel print the CPU information it was
Am I reading this correctly--the address of the main() function for a
process is guaranteed to be the lowest possible virtual address?
chris
It is one of the lowest. The 'C' runtime library puts section
.text (the code) first, then .data, then .bss, then .stack. The
.stack section
> > 2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) :
> > extern void __bad_udelay(void);
> >
> > #define udelay(n) (__builtin_constant_p(n) ? \
> > ((n) > 2 ? __bad_udelay() : __const_udelay((n) *
> > 0x10c6ul)) : \
> > __udelay(n))
> >
> > ...
> > It seems
To clarify: you're getting missing-symbol errors (not duplicate-symbols)?
I believe that the "return" versions of these macros have been deprecated.
There's an effort going on to replace these functions with a standard
"put_user(); return;" pair. People think that having a macro which returns
To clarify: you're getting missing-symbol errors (not duplicate-symbols)?
I believe that the "return" versions of these macros have been deprecated.
There's an effort going on to replace these functions with a standard
"put_user(); return;" pair. People think that having a macro which returns
I didn't want to post to the list with this, but [EMAIL PROTECTED]
didn't get a reply.
The NNTP gateway hasn't been working for two weeks-- the last list message
was 9/2/2000. Maybe this is common knowledge on the list (since I'm not
subscribed, I obviously wouldn't know...) but it's a little
I didn't want to post to the list with this, but [EMAIL PROTECTED]
didn't get a reply.
The NNTP gateway hasn't been working for two weeks-- the last list message
was 9/2/2000. Maybe this is common knowledge on the list (since I'm not
subscribed, I obviously wouldn't know...) but it's a little
29 matches
Mail list logo
