From mboxrd@z Thu Jan  1 00:00:00 1970
References: <E9D002A0-CF5A-4059-96F9-9365F67D119B@ar.aichi-u.ac.jp>
	<0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org>
	<44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net>
	<7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp>
	<4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net>
	<D6B3E614-CD6D-443E-8389-C7258D90954F@ar.aichi-u.ac.jp>
	<c7f91b490366efbf73cc704d9f3bc4e1@brasstown.quanstro.net>
	<D9E6D4D0-8216-4020-8E38-B580A8828564@ar.aichi-u.ac.jp>
	<3a6fb8671dae34eb5b4e0ebe3992bcfd@brasstown.quanstro.net>
	<C8AD9779-9F94-496A-A9D1-246A7A3453E4@ar.aichi-u.ac.jp>
	<1fccf1df5e46d5fa5235a40a90a001e3@brasstown.quanstro.net>
	<A97D4AC3-3160-448A-BAAE-562FD1529B6C@ar.aichi-u.ac.jp>
From: Quintile <steve@quintile.net>
Content-Type: text/plain;
	charset=utf-8
In-Reply-To: <A97D4AC3-3160-448A-BAAE-562FD1529B6C@ar.aichi-u.ac.jp>
Message-Id: <068F2ED1-D863-47CC-A72F-4BFE5A17144C@quintile.net>
Date: Wed, 28 Jan 2015 07:48:42 +0000
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: [9fans] protection against resource exhaustion
Topicbox-Message-UUID: 3ce3d532-ead9-11e9-9d60-3106f5b1d025

I always thought the best solution for a university system, is to implement t=
he fair share scheduler. thus people can use any resource the want on an idl=
e machine, but a saturated machine splits its load based on rules.

I had this experience when I managed a cray (YMP-El only) and it worked perf=
ectly. it did not limit processes per user, but it could.

similarly ram use and network bandwidth - though this only works per machine=
.

personally I like erik's idea, though I would make it a boot option.

I would also keep malloc() returning nil on fail, but add emalloc() to libc.=

and finally have an environment car that makes emalloc() clas sys fatal)) or=
 abort() - for debug.

Steve





> On 28 Jan 2015, at 06:50, arisawa <arisawa@ar.aichi-u.ac.jp> wrote:
>=20
> Hello,
>=20
>> nonetheless, i have experience running multi-user plan 9 systems, and use=
rs
>> were not usually the issue.
>=20
> Eric=E2=80=99s users are all gentleman, all careful people and all skillfu=
l programmers.
> If your system is served for university students, you will have different t=
hought.
>=20
>> i think you've turned a problem with bounded recovery time into a
>> situation where the recovery code itself will inadvertently dos attack it=
s
>> users.
>=20
> in case that a process failed in getting resource such as memory or proces=
s,=20
> what it should do is very limited: puts out some message and exits.
> this is right behavior.
> I have never seen programs that retry malloc() or fork() until succeed.
> if all processes retry them, the system will get down.
> this is what I have observed in current plan9 kernel.
>=20
> if any one has cleaner solution, i.e., a solution that never kill innocent=
 process,
> I want to see it.
>=20
>=20