> You might also be running services on it, and it's reasonable that it
> should manage its resources. It's best to refuse a new load if it
> won't fit, but that requires a fairly careful system design and works
> best in closed systems. In a capability system you'd have to present
> a capability
> Nevertheless all programs, I believe, in /sys/src are written assuming
> rfork() may return -l:
* cifs keepalive thread may not start
* ssh2 will malfunction in ssh.c
* htmlroff will malfunction
* imap4d idle will fail with no warning
* upas/scanmail:/^qmail, same issue
* page/gs.c will die wie
Thanks for all.
I have looked old source code /sys/src/9/port/proc.c, and found the next code
exists from very old day.
lock(&procalloc);
for(;;) {
if((p = procalloc.free) != nil)
break;
snprint(msg, sizeof msg, "no procs;
On 28 January 2015 at 17:39, wrote:
> your mail got cut off after "I think a"
I'd moved the body of that paragraph into the first paragraph, but that bit
had scrolled out of sight.
your mail got cut off after "I think a"
--
cinap
On 28 January 2015 at 06:50, arisawa wrote:
> Eric’s users are all gentleman, all careful people and all skillful
> programmers.
> If your system is served for university students, you will have different
> thought.
>
You might also be running services on it, and it's reasonable that it
should m
as someone mentioned, a dedicated real or virtual term (9vx, rpi+9pi) is
the right option. is there a reason this might not work for your
environment?
as for system watchdog, usually an external subsystem is used. i wonder if
a cpu (e.g. 9pi) dedicated to monitoring the main cpu's /proc (and perha
I don't see any error here. Only a few minor warnings.
--
David du Colombier
So I am getting a bunch of errors when recompiling plan9port on yosemite…
$ ./INSTALL
+ Mailing list: http://groups.google.com/group/plan9port-dev
+ Issue tracker: http://code.swtch.com/plan9port/issues/
+ Submitting changes: http://swtch.com/go/codereview
* Resetting /usr/local/plan9/config
* C
> look for the x10-slr. the -f is for ipmi (boo) and i don't know
> what the -o stands for because it wasn't on the website.
-O is retail and -B is bulk, as far as I understand Supermicro's
nomenclature.
--
David du Colombier
> the reason is that each process can have up to 16mb of stack, and this is
> unaccounted.
> thus the stack or (seg)?brk can commit to memory that will fault when you
> touch it.
It's a vague recollection, but the fact that the stack is being
overcommitted rings a bell. Thanks, Erik.
Lucio.
On Tue Jan 27 22:46:22 PST 2015, aris...@ar.aichi-u.ac.jp wrote:
> Hello,
>
> > nonetheless, i have experience running multi-user plan 9 systems, and users
> > were not usually the issue.
>
> Eric’s users are all gentleman, all careful people and all skillful
> programmers.
> If your system is s
On Wed Jan 28 06:05:50 PST 2015, lu...@proxima.alt.za wrote:
> > i'd forgotten the added difficulty with the 32-bit kernels that plan 9
> > overcommits
> > memory. so in a low-memory situation, a process can be killed by using more
> > stack!
>
> I could have sworn I heard otherwise. But things
> i'd forgotten the added difficulty with the 32-bit kernels that plan 9
> overcommits
> memory. so in a low-memory situation, a process can be killed by using more
> stack!
I could have sworn I heard otherwise. But things sometimes are not as I think
they are. Here, I'm very curious to know
On Wed Jan 28 00:31:49 PST 2015, 0in...@gmail.com wrote:
> > what motherboard and model did you use. it would be
> > good to buy something known to work.
>
> I bought a Supermicro X10SAE motherboard last year.
> It uses the same Intel i210 Ethernet controller as
> Erik's new motherboard. It works
> > in case that a process failed in getting resource such as memory or
> > process,
> > what it should do is very limited: puts out some message and exits.
> > this is right behavior.
>
> practically, for most simple programs fork error is handled by sysfatal().
> but things get more tricky for
> in case that a process failed in getting resource such as memory or process,
> what it should do is very limited: puts out some message and exits.
> this is right behavior.
practically, for most simple programs fork error is handled by sysfatal().
but things get more tricky for libthread progra
> what motherboard and model did you use. it would be
> good to buy something known to work.
I bought a Supermicro X10SAE motherboard last year.
It uses the same Intel i210 Ethernet controller as
Erik's new motherboard. It works quite nicely.
--
David du Colombier
I always thought the best solution for a university system, is to implement the
fair share scheduler. thus people can use any resource the want on an idle
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
per
19 matches
Mail list logo
