linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Veltzer <mark@veltzer.org>
To: Peter Svensson <petersv@psv.nu>,
	Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: Offtopic: (was Re: [ANNOUNCE] Native POSIX Thread Library 0.1)
Date: Tue, 24 Sep 2002 18:19:35 +0300	[thread overview]
Message-ID: <200209241519.g8OFJcB26734@www.veltzer.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0209241646170.2383-100000@cheetah.psv.nu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 24 September 2002 17:50, Peter Svensson wrote:
> Either you need to educate your users and trust them to
> behave, or you need per user scheduling.

It is obvious that in high end systems you MUST have per user scheduling 
since users will rob each other of cycles.... If Linux is to be a general 
purpose operation system it MUST have this feature (otherwise it will only be 
considered fit for lower end systems) and trusting your users at this no 
better than trusting your users when they promise you they will not seg fault 
or peek into memory pages which are not theirs. It simply isn't done. 
Besides, using the CPU in an abusive manner could happen as a result of a bug 
as much as a result of malicious intent (exactly like a segfault).

Ok. Here's an idea. Why not have both ?!?

There is no real reason why I should have per user scheduling on my machine 
at home (I don't really need a just devision of labour between the root user 
and myself which are almost the only users to use my system). Why not have 
the deault compilation of the kernel be without per user scheduling and 
enable it for high end systems (like a university machine where all the 
students are at each others throats for a few CPU cycles...) ? So how about 
making this a compile option and let the users decide what they like ?

Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9kIKHxlxDIcceXTgRAjGTAJ9bj1t2QV3zaDheO3GQpvJxxjDSIQCggESi
yqE29XtjTL3VDBu15VTQ0Qc=
=oueS
-----END PGP SIGNATURE-----

  reply	other threads:[~2002-09-24 15:02 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-22 18:55 [ANNOUNCE] Native POSIX Thread Library 0.1 Peter Waechtler
2002-09-22 21:32 ` Larry McVoy
2002-09-23 10:05   ` Bill Davidsen
2002-09-23 11:55     ` Peter Waechtler
2002-09-23 19:14       ` Bill Davidsen
2002-09-29 23:26         ` Buddy Lumpkin
2002-09-30 14:54           ` Corey Minyard
2002-09-23 15:30     ` Larry McVoy
2002-09-23 19:44       ` Olivier Galibert
2002-09-23 19:48       ` Bill Davidsen
2002-09-23 20:32         ` Ingo Molnar
2002-09-24  0:03           ` Andy Isaacson
2002-09-24  0:10             ` Jeff Garzik
2002-09-24  0:14               ` Andy Isaacson
2002-09-24  5:53             ` Ingo Molnar
2002-09-24 20:34             ` David Schwartz
2002-09-24  7:12           ` Thunder from the hill
2002-09-24  7:30             ` Ingo Molnar
2002-09-23 22:35         ` Mark Mielke
2002-09-23 19:59       ` Peter Waechtler
2002-09-23 20:36         ` Ingo Molnar
2002-09-23 21:08           ` Peter Wächtler
2002-09-23 22:44             ` Mark Mielke
2002-09-23 23:01               ` Bill Huey
2002-09-23 23:11                 ` Mark Mielke
2002-09-24  0:21                   ` Bill Huey
2002-09-24  3:20                     ` Mark Mielke
2002-09-23 23:57           ` Andy Isaacson
2002-09-24  6:32             ` 1:1 threading vs. scheduler activations (was: Re: [ANNOUNCE] Native POSIX Thread Library 0.1) Ingo Molnar
2002-09-25  3:08               ` Bill Huey
2002-09-24 18:10             ` [ANNOUNCE] Native POSIX Thread Library 0.1 Christoph Hellwig
2002-09-23 21:32       ` Bill Huey
2002-09-23 21:41       ` dean gaudet
2002-09-23 22:10         ` Bill Huey
2002-09-23 22:56         ` Mark Mielke
2002-09-24 10:02       ` Nikita Danilov
2002-09-23 21:22     ` Bill Huey
2002-09-23 21:03 ` Bill Huey
2002-09-24 12:03   ` Michael Sinz
2002-09-24 13:40     ` Peter Svensson
2002-09-24 14:20       ` Michael Sinz
2002-09-24 14:50         ` Offtopic: (was Re: [ANNOUNCE] Native POSIX Thread Library 0.1) Peter Svensson
2002-09-24 15:19           ` Mark Veltzer [this message]
2002-09-24 17:29             ` Rik van Riel
2002-09-25 18:57               ` Mark Mielke
2002-09-25 19:04                 ` Rik van Riel
2002-09-25 19:29                   ` Mark Veltzer
2002-09-25 19:23                     ` Rik van Riel
2002-09-24 16:31           ` Rik van Riel
2002-09-24 18:49             ` Michael Sinz
2002-09-24 19:12               ` PATCH: per user fair scheduler 2.4.19 (cleaned up, thanks hch) (was: Re: Offtopic: (was Re: [ANNOUNCE] Native POSIX Thread Library 0.1)) Rik van Riel
2002-09-24 20:19 ` [ANNOUNCE] Native POSIX Thread Library 0.1 David Schwartz
2002-09-24 21:10   ` Chris Friesen
2002-09-24 21:22     ` Rik van Riel
2002-09-24 21:35       ` Roberto Peon
2002-09-24 21:35       ` Chris Friesen
2002-09-25 19:02     ` David Schwartz
2002-09-24 23:16   ` Peter Waechtler
2002-09-24 23:23     ` Rik van Riel
2002-09-25 19:05     ` David Schwartz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200209241519.g8OFJcB26734@www.veltzer.org \
    --to=mark@veltzer.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=petersv@psv.nu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).