[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler
- To: Marco Colombo <marco@esi.it>
- Subject: Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler
- From: Kurt Garloff <garloff@suse.de>
- Date: Mon, 9 Oct 2000 18:26:51 +0200
- Cc: Rik van Riel <riel@conectiva.com.br>, linux-mm@kvack.org, linux-kernel@vger.kernel.org
- In-Reply-To: <Pine.LNX.4.21.0010091159430.20087-100000@Megathlon.ESI>; from marco@esi.it on Mon, Oct 09, 2000 at 12:12:02PM +0200
- Mail-Followup-To: Kurt Garloff <garloff@suse.de>,Marco Colombo <marco@esi.it>, Rik van Riel <riel@conectiva.com.br>,linux-mm@kvack.org, linux-kernel@vger.kernel.org
- Organization: TUE/NL, SuSE/FRG
- References: <Pine.LNX.4.21.0010061721520.13585-100000@duckman.distro.conectiva> <Pine.LNX.4.21.0010091159430.20087-100000@Megathlon.ESI>
- Sender: owner-linux-mm@kvack.org
- User-Agent: Mutt/1.2.5i
On Mon, Oct 09, 2000 at 12:12:02PM +0200, Marco Colombo wrote:
> On Fri, 6 Oct 2000, Rik van Riel wrote:
> [...]
> > They are niced because the user thinks them a bit less
> > important.
>
> Please don't, this assumption is quite wrong. I use nice just to be
> 'nice' to other users. I can run my *important* CPU hog simulation
> nice +10 in order to let other people get more CPU when the need it.
> But if you put the logic "niced == not important" somewhere into the
> kernel, nobody will use nice anymore. I'd rather give a bonus to niced
> processes.
I could not agree more. Normally, you'd better kill a foreground task
(running nice 0) than selecting one of those background jobs for some
reasons:
* The foreground job can be restarted by the interactive user
(Most likely, it will be only netscape anyway)
* The background job probably is the more useful one which has been running
since a longer time (computations, ...)
* If we put any policy like this into the kernel at all, I'd rather
encourage the usage of nice instead of discouraging it.
I assume here backgrd job == niced job, which mostly is the case in reality.
Regards,
--
Kurt Garloff <garloff@suse.de> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
PGP signature