[9fans] 9vx bootimage build instructions?

[9fans] 9vx bootimage build instructions?

[EBo]

 Doing some multipipe testing I'm running out of procs.  I was able to
 build a hacked boot image run under kvm, and now would like to do the
 same for 9vx.

 Looking at sys/lib/dist/pc/plan9.ini, the images reference by both
 bootfile and nobootprompt do not exist.  Can someone give me the recipe
 for the special sauce to build/install a new boot image into 9vx?

   Thanks and best regards,

   EBo --

Re: [9fans] 9vx bootimage build instructions?

[erik quanstrom]

On Wed May 25 23:29:13 EDT 2011, ebo@sandien.com wrote:
>  Doing some multipipe testing I'm running out of procs.  I was able to
>  build a hacked boot image run under kvm, and now would like to do the
>  same for 9vx.
>
>  Looking at sys/lib/dist/pc/plan9.ini, the images reference by both
>  bootfile and nobootprompt do not exist.  Can someone give me the recipe
>  for the special sauce to build/install a new boot image into 9vx?

9vx uses plan9.ini?  last i checked, that assumption was false.

i think you need to modify the 9vx kernel directly.

- erik

Re: [9fans] 9vx bootimage build instructions?

[EBo]

 On Wed, 25 May 2011 23:37:46 -0400, erik quanstrom wrote:
> 9vx uses plan9.ini?  last i checked, that assumption was false.
>
> i think you need to modify the 9vx kernel directly.

 That would explain why I could not find the links 8-/  The nprocs are
 hacked now...

 What is the easiest way to set the memory?  I'm running out of memory
 too.

   EBo --

Re: [9fans] 9vx bootimage build instructions?

[EBo]

 On Wed, 25 May 2011 22:58:50 -0500, EBo wrote:
>
> What is the easiest way to set the memory?  I'm running out of memory
> too.

 I found a way to set the default, but there does not appear to be an
 easy way to pass the argument in.  Suggestions?

   EBo --

Re: [9fans] 9vx bootimage build instructions?

[Devon H. O'Dell]

I'm pretty sure yiyus's tree (which should be merged to ron's) has a
patch I made a few years ago to set max memory (which is the initial
bit it mmap's in)

--dho

2011/5/26 EBo <ebo@sandien.com>:
> On Wed, 25 May 2011 22:58:50 -0500, EBo wrote:
>>
>> What is the easiest way to set the memory?  I'm running out of memory too.
>
> I found a way to set the default, but there does not appear to be an easy
> way to pass the argument in.  Suggestions?
>
>  EBo --
>
>
>

Re: [9fans] 9vx bootimage build instructions?

[Bakul Shah]

On Wed, 25 May 2011 23:05:32 CDT EBo <ebo@sandien.com>  wrote:
>  On Wed, 25 May 2011 22:58:50 -0500, EBo wrote:
> >
> > What is the easiest way to set the memory?  I'm running out of memory
> > too.
>
>  I found a way to set the default, but there does not appear to be an
>  easy way to pass the argument in.  Suggestions?
>
>    EBo --

9vx memsize=314 $*

from Ron's hg repo. Also see examples in vx32/bin.

Re: [9fans] 9vx bootimage build instructions?

[yy]

2011/5/26 erik quanstrom <quanstro@quanstro.net>:
> 9vx uses plan9.ini?  last i checked, that assumption was false.

That depends where you checked. Ron's version (or mine, they are the
same now) has some support for plan9.ini files with the -f flag, as is
documented in the man page:
http://bytebucket.org/yiyus/vx32/wiki/9vx.html. However, although
plan9.ini is used to set some config values (as the root file system
or the memory limit mentioned in this thread), 9vx cannot load a
kernel file. So:

> i think you need to modify the 9vx kernel directly.

is right.

Modifying the 9vx kernel is not funny because of the bad state of the
.ed files in a/. I hope newer versions of gcc with plan9 extensions
make most of these scripts unnecessary, but as far as I know nobody
has tried.

-- 
- yiyus || JGL .

[9fans] 9vx patches [was: 9vx bootimage build instructions?]

[EBo]

 On Thu, 26 May 2011 09:40:31 +0200, yy wrote:
> 2011/5/26 erik quanstrom <quanstro@quanstro.net>:
>> 9vx uses plan9.ini?  last i checked, that assumption was false.
>
> That depends where you checked. Ron's version (or mine, they are the
> same now) has some support for plan9.ini files with the -f flag, as 
> is
> documented in the man page:
> http://bytebucket.org/yiyus/vx32/wiki/9vx.html. However, although
> plan9.ini is used to set some config values (as the root file system
> or the memory limit mentioned in this thread), 9vx cannot load a
> kernel file. So:

 There was a minor inconsistency.  There is a comment in 9vx/mmu.c which 
 states that memsize can be overwritten with the '-m' option, but no -m 
 switch was provided in main.  The following diff adds that (tested):

 --- main.c      2011-05-26 08:34:02.687051389 -0500
 +++ main.c      2011-05-26 08:34:10.830709411 -0500
 @@ -170,6 +170,9 @@
                 username = EARGF(usage());
                 break;
 
 +       case 'm':
 +               memsize = atoi(EARGF(usage()));
 +               break;
         default:
                 usage();
         }ARGEND

 Also, thanks for the pointer.  Setting memsize in a plan9.ini also 
 works.

>> i think you need to modify the 9vx kernel directly.
>
> is right.
>
> Modifying the 9vx kernel is not funny because of the bad state of the
> .ed files in a/. I hope newer versions of gcc with plan9 extensions
> make most of these scripts unnecessary, but as far as I know nobody
> has tried.

 The following command line switch (-n) adds an initial hack to 
 conf.nproc to override the 2000 hard coded limit.  While this allws me 
 to now run over 64 threads, running it to high gives me a warning that 
 there are to many procs for devproc.  I'm providing the patch here as 
 is, but will likely take a poke at it again over the weekend.  As a 
 note, I need to be able to spawn over 3000 procs to stress test some 
 code.  I would like to get this working under 9vx as well...

 --- main.c	2011-05-26 08:40:00.286043255 -0500
 +++ main.c	2011-05-26 08:43:42.369712636 -0500
 @@ -64,6 +64,8 @@
 
  static char*	getuser(void);
 
 +int nproclimit = 2000; // allow override of the hardlimit set to the 
 number of procs
 +
  void
  usage(void)
  {
 @@ -173,6 +175,9 @@
  	case 'm':
  		memsize = atoi(EARGF(usage()));
  		break;
 +	case 'n':
 +		nproclimit = atoi(EARGF(usage()));
 +		break;
  	default:
  		usage();
  	}ARGEND
 @@ -284,8 +289,8 @@
  		conf.npage += conf.mem[i].npage;
  	conf.upages = conf.npage;
  	conf.nproc = 100 + ((conf.npage*BY2PG)/MB)*5;
 -	if(conf.nproc > 2000)
 -		conf.nproc = 2000;
 +	if(conf.nproc > nproclimit)
 +		conf.nproc = nproclimit;
  	conf.nimage = 200;
  	conf.nswap = 0;
  	conf.nswppo = 0;

 I do not think I have write access to your 9vx repository, and I do not 
 know if you want the nproc limit hack.  Let me know if you find these 
 acceptable.

   EBo --

Re: [9fans] 9vx patches [was: 9vx bootimage build instructions?]

[Devon H. O'Dell]

2011/5/26 EBo <ebo@sandien.com>:
> On Thu, 26 May 2011 09:40:31 +0200, yy wrote:
>>
>> 2011/5/26 erik quanstrom <quanstro@quanstro.net>:
>>>
>>> 9vx uses plan9.ini?  last i checked, that assumption was false.
>>
>> That depends where you checked. Ron's version (or mine, they are the
>> same now) has some support for plan9.ini files with the -f flag, as is
>> documented in the man page:
>> http://bytebucket.org/yiyus/vx32/wiki/9vx.html. However, although
>> plan9.ini is used to set some config values (as the root file system
>> or the memory limit mentioned in this thread), 9vx cannot load a
>> kernel file. So:
>
> There was a minor inconsistency.  There is a comment in 9vx/mmu.c which
> states that memsize can be overwritten with the '-m' option, but no -m
> switch was provided in main.  The following diff adds that (tested):

Yeah, I added this option years ago but it must have been lost in some
of the SoC work plus merges at some point.

> --- main.c      2011-05-26 08:34:02.687051389 -0500
> +++ main.c      2011-05-26 08:34:10.830709411 -0500
> @@ -170,6 +170,9 @@
>                username = EARGF(usage());
>                break;
>
> +       case 'm':
> +               memsize = atoi(EARGF(usage()));
> +               break;
>        default:
>                usage();
>        }ARGEND
>
> Also, thanks for the pointer.  Setting memsize in a plan9.ini also works.

Or maybe yiyus added it here in an attempt to get things out of CLI
opts when the plan9.ini stuff happened.

>>> i think you need to modify the 9vx kernel directly.
>>
>> is right.
>>
>> Modifying the 9vx kernel is not funny because of the bad state of the
>> .ed files in a/. I hope newer versions of gcc with plan9 extensions
>> make most of these scripts unnecessary, but as far as I know nobody
>> has tried.
>
> The following command line switch (-n) adds an initial hack to conf.nproc to
> override the 2000 hard coded limit.  While this allws me to now run over 64
> threads, running it to high gives me a warning that there are to many procs
> for devproc.  I'm providing the patch here as is, but will likely take a
> poke at it again over the weekend.  As a note, I need to be able to spawn
> over 3000 procs to stress test some code.  I would like to get this working
> under 9vx as well...
>
> --- main.c      2011-05-26 08:40:00.286043255 -0500
> +++ main.c      2011-05-26 08:43:42.369712636 -0500
> @@ -64,6 +64,8 @@
>
>  static char*   getuser(void);
>
> +int nproclimit = 2000; // allow override of the hardlimit set to the number
> of procs
> +
>  void
>  usage(void)
>  {
> @@ -173,6 +175,9 @@
>        case 'm':
>                memsize = atoi(EARGF(usage()));
>                break;
> +       case 'n':
> +               nproclimit = atoi(EARGF(usage()));
> +               break;
>        default:
>                usage();
>        }ARGEND
> @@ -284,8 +289,8 @@
>                conf.npage += conf.mem[i].npage;
>        conf.upages = conf.npage;
>        conf.nproc = 100 + ((conf.npage*BY2PG)/MB)*5;
> -       if(conf.nproc > 2000)
> -               conf.nproc = 2000;
> +       if(conf.nproc > nproclimit)
> +               conf.nproc = nproclimit;
>        conf.nimage = 200;
>        conf.nswap = 0;
>        conf.nswppo = 0;
>
> I do not think I have write access to your 9vx repository, and I do not know
> if you want the nproc limit hack.  Let me know if you find these acceptable.

Typically the way to do this is to create your own public fork, and
then send a pull request to the maintainer of whoever you forked from
since hg has the distributed model.

>  EBo --
>
>
>

[9fans] hgfs?

[Bakul Shah]

> Typically the way to do this is to create your own public fork, and
> then send a pull request to the maintainer of whoever you forked from
> since hg has the distributed model.

A project idea: murkyfs -- browse not just your own mercurial
repo and also the one you cloned from! Extra points for
mapping hg commands like push/pull/merge/diff in a useful way.

Another idea is a better integration of acem + hg.  [One side
effect using Eclipse is I have been thinking about how one
might build a simple IDE around acme or something similar.]

Re: [9fans] hgfs?

[simon softnet]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

do you even realize that plan 9 / unix is supposed to be an IDE?

On Thu, May 26, 2011 at 6:39 PM, Bakul Shah <bakul@bitblocks.com> wrote:

> > Typically the way to do this is to create your own public fork, and
> > then send a pull request to the maintainer of whoever you forked from
> > since hg has the distributed model.
>
> A project idea: murkyfs -- browse not just your own mercurial
> repo and also the one you cloned from! Extra points for
> mapping hg commands like push/pull/merge/diff in a useful way.
>
> Another idea is a better integration of acem + hg.  [One side
> effect using Eclipse is I have been thinking about how one
> might build a simple IDE around acme or something similar.]
>
>

[-- Attachment #2: Type: text/html, Size: 987 bytes --]

Re: [9fans] hgfs?

[Iruatã Souza]

On Thu, May 26, 2011 at 1:39 PM, Bakul Shah <bakul@bitblocks.com> wrote:
>> Typically the way to do this is to create your own public fork, and
>> then send a pull request to the maintainer of whoever you forked from
>> since hg has the distributed model.
>
> A project idea: murkyfs -- browse not just your own mercurial
> repo and also the one you cloned from! Extra points for
> mapping hg commands like push/pull/merge/diff in a useful way.
>
> Another idea is a better integration of acem + hg.  [One side
> effect using Eclipse is I have been thinking about how one
> might build a simple IDE around acme or something similar.]
>
>
http://ueber.net/code/r/hgfs

Re: [9fans] hgfs?

[erik quanstrom]

> > A project idea: murkyfs -- browse not just your own mercurial
> > repo and also the one you cloned from! Extra points for
> > mapping hg commands like push/pull/merge/diff in a useful way.
> >
> > Another idea is a better integration of acem + hg.  [One side
> > effect using Eclipse is I have been thinking about how one
> > might build a simple IDE around acme or something similar.]
> >
> >
> http://ueber.net/code/r/hgfs

file servers are great, but hg concepts aren't really file-system oriented.
it might be nice to be able to
	diff -c (default mybranch)^/sys/src/9/pc/mp.c
but hg diff figures out all the alloying stuff, like the top-level of the
repo anyway.  also, ideas like push, pull, update, etc., don't map very well.
so a hg file server seems to me a bit like, "have hammer, see nail".

if i'm missing why this is an interesting idea, i'd love to know what
i don't see.

- erik

Re: [9fans] hgfs?

[Bakul Shah]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]

On Thu, 26 May 2011 20:16:11 EDT erik quanstrom <quanstro@quanstro.net>  wrote:
> > > A project idea: murkyfs -- browse not just your own mercurial
> > > repo and also the one you cloned from! Extra points for
> > > mapping hg commands like push/pull/merge/diff in a useful way.
> > >
> > > Another idea is a better integration of acem + hg.  [One side
> > > effect using Eclipse is I have been thinking about how one
> > > might build a simple IDE around acme or something similar.]
> > >
> > >
> > http://ueber.net/code/r/hgfs
>
> file servers are great, but hg concepts aren't really file-system oriented.
> it might be nice to be able to
> 	diff -c (default mybranch)^/sys/src/9/pc/mp.c
> but hg diff figures out all the alloying stuff, like the top-level of the
> repo anyway.  also, ideas like push, pull, update, etc., don't map very well.
> so a hg file server seems to me a bit like, "have hammer, see nail".

May be the filesystem model is more like an electric motor
that powers all sorts of things given the right attachment!

> if i'm missing why this is an interesting idea, i'd love to know what
> i don't see.

I partially agree with you; hence the suggestion about editor
integration. But I am wondering just how far this model can be
pushed or extended seamlessly.

Features such as atomic commits, changesets, branches, push,
pull, merge etc. can be useful in multiple contexts so it
would be nice if they can integrated smoothly in an FS.

Example uses:
- A backup is nothing but a previous commit. A nightly
  backup cron job to do "echo `{date} > .commit"
- Initial system install is like a clone.
- An OS upgrade is like a pull.
- Installing a package is like a pull (or if you built it
  locally, a commit)
- Uinstall is reverting the change.
- Each machine's config can be in its own branch.
- You can use clone to create sandboxes.
- A commit makes your private temp view permanent and
  potentially visible to others.
- Conversely old commits can be spilled to a backup
  media (current SCMs want the entire history online).

Now we can map a specific file version to one specific path --
this is what hgfs above does.  But what about push/pull/commit
etc.? One idea is to to map them to operations on "magic"
files.

For example,
- local file copies appear as normal files.
- cat .status  == hg status
- cat > .commit == hg commit
- cat .log == hg log
- echo -a > .revert == hg revert -a
- echo $url > .push == hg push $url
- echo $url > .pull == hg push -u $url

In fact the backend SCM doesn't have to be mercurial; it can
also git or even venti etc. Can we come up with a minimal set?

Do we gain anything by mapping $SCM commands to special files?
What about name clashes?

Re: [9fans] hgfs?

[erik quanstrom]

> > if i'm missing why this is an interesting idea, i'd love to know what
> > i don't see.
>
> I partially agree with you; hence the suggestion about editor
> integration. But I am wondering just how far this model can be
> pushed or extended seamlessly.
>
> Features such as atomic commits, changesets, branches, push,
> pull, merge etc. can be useful in multiple contexts so it
> would be nice if they can integrated smoothly in an FS.
>
> Example uses:
> - A backup is nothing but a previous commit. A nightly
>   backup cron job to do "echo `{date} > .commit"
> - Initial system install is like a clone.

the problem here is that no scm that i know of has storage
capabilities.  you'd still need a file system underneath.  it
sounds like you're proposing something completely different
than hg, even if it's compatable on some level.

> - An OS upgrade is like a pull.

is like, but they're different.  you can't take every file from
the base.  one of the problems with replica is that it's hard
to work out the local differences.  hg doesn't make this any
easier.

> - Installing a package is like a pull (or if you built it
>   locally, a commit)
> - Uinstall is reverting the change.
> - Each machine's config can be in its own branch.
> - You can use clone to create sandboxes.
> - A commit makes your private temp view permanent and
>   potentially visible to others.

this is interesting, but what you're talking about sounds a
lot more like user-controlled snapshotting than scm to me.

do you propose being able to do this at any level in the fs
heirarchy, or just at the root?  if not just at the root, how
is a namespace constructed?

i'm not sure why one would want each machine's config in
its own branch.  remerging default could be a real administrative
pain.  in fact, i wonder how one would keep things sane.
how would build some cannonical rules, like we have for
the namespace (namespace(4))?

> - Conversely old commits can be spilled to a backup
>   media (current SCMs want the entire history online).

backup media?  what's that?  ;-)

i'd be against any scheme that moves data from its original
location.  the worm property is just great.  i've reconstructed
full worms from partial worms a few times.  russ posted an
interesting story about recovering a venti this way.

- erik

http://www.quanstro.net/magic/man2html/4/namespace

Re: [9fans] hgfs?

[Lucio De Re]

On Fri, May 27, 2011 at 08:21:14AM -0400, erik quanstrom wrote:
>
> do you propose being able to do this at any level in the fs
> heirarchy, or just at the root?  if not just at the root, how
> is a namespace constructed?
>
I'm going to throw a small pebble into this pond, in case it goes
overlooked: "proto".  I'm not sure how helpful it might be, but it pops
up in my head whenever I think about revision control for a native Plan
9 platform.

++L

Re: [9fans] hgfs?

[Bakul Shah]

On Fri, 27 May 2011 08:21:14 EDT erik quanstrom <quanstro@quanstro.net>  wrote:
> >
> > Features such as atomic commits, changesets, branches, push,
> > pull, merge etc. can be useful in multiple contexts so it
> > would be nice if they can integrated smoothly in an FS.
> >
> > Example uses:
> > - A backup is nothing but a previous commit. A nightly
> >   backup cron job to do "echo `{date} > .commit"
> > - Initial system install is like a clone.
>
> the problem here is that no scm that i know of has storage
> capabilities.  you'd still need a file system underneath.

Yes.

> it
> sounds like you're proposing something completely different
> than hg, even if it's compatable on some level.

Perhaps a subset. I don't know.

> > - An OS upgrade is like a pull.
>
> is like, but they're different.  you can't take every file from
> the base.  one of the problems with replica is that it's hard
> to work out the local differences.  hg doesn't make this any
> easier.

You can keep a `vendor' branch in sync with the base.  local
changes in a separate `local' branch. Do a merge periodically.

> this is interesting, but what you're talking about sounds a
> lot more like user-controlled snapshotting than scm to me.

Use controlled snapshotting is basically what an scm does.  In
addition you can revert changes, maintain alternative
branches, share your changes with others and so on.

> do you propose being able to do this at any level in the fs
> heirarchy, or just at the root?  if not just at the root, how
> is a namespace constructed?

Yes, at any level. Wherever you might put .hg.  But I haven't
worked out lots of things.

> i'm not sure why one would want each machine's config in
> its own branch.  remerging default could be a real administrative
> pain.

In fact I used to keep configurations under scm.  Handy when
multiple machines have to be managed.

> in fact, i wonder how one would keep things sane.
> how would build some cannonical rules, like we have for
> the namespace (namespace(4))?

Don't know.  Since you asked if this is an interesting idea I
wrote up what I was thinking about but that doesn't mean much
of it is worked out!  This is research :-) Lots of half baked
ideas to sort through, lots of open questions.  On prototyping
it may turn out none of it makes any sense.

> > - Conversely old commits can be spilled to a backup
> >   media (current SCMs want the entire history online).
>
> backup media?  what's that?  ;-)

Or offsite.

A better integration can inspire new uses (at least for me
this is the case).
- a timemachine like program to animate changes in a file (or
  even a bird's eye view of changes in an entire repo). Scroll
  backward/forward in time.
- combining versioning + scripted push/pull can open up new
  new uses. For instance, commit before refetching pages from
  a website into webfs, and you can keep your own archive.
  Your own wayback machine :-)
- since each changeset has a unique signature, you don't have
  to fetch/keep an entire repo locally if you can fetch it
  from another node (but you can).  Instead you can share a
  repo with other people and only keep your local changes.
- Given this, you can boot up a new machine, configure it
  minimally, install this fs and start using the machine right
  away as things will be fetched on demand.  This is just
  using existing mechanisms in an SCM in a new way (but
  perhaps bending it in an extreme way).

Re: [9fans] hgfs?

[erik quanstrom]

> - a timemachine like program to animate changes in a file (or
>   even a bird's eye view of changes in an entire repo). Scroll
>   backward/forward in time.

history(1).

- erik

Re: [9fans] 9vx patches [was: 9vx bootimage build instructions?]

[erik quanstrom]

>  The following command line switch (-n) adds an initial hack to
>  conf.nproc to override the 2000 hard coded limit.  While this allws me
>  to now run over 64 threads, running it to high gives me a warning that
>  there are to many procs for devproc.  I'm providing the patch here as

this is a bug in the warning message.

; diffy -c devproc.c
/n/dump/2011/0526/sys/src/9/port/devproc.c:139,147 - devproc.c:139,149
   * If notepg, c->pgrpid.path is pgrp slot, .vers is noteid.
   */
  #define	QSHIFT	5	/* location in qid of proc slot # */
+ #define	SLOTBITS 23	/* number of bits in the slot */
+ #define	SLOTMASK	((1<<SLOTBITS)-1 << QSHIFT)

  #define	QID(q)		((((ulong)(q).path)&0x0000001F)>>0)
- #define	SLOT(q)		(((((ulong)(q).path)&0x07FFFFFE0)>>QSHIFT)-1)
+ #define	SLOT(q)		(((((ulong)(q).path)&SLOTMASK)>>QSHIFT)-1)
  #define	PID(q)		((q).vers)
  #define	NOTEID(q)	((q).vers)

/n/dump/2011/0526/sys/src/9/port/devproc.c:288,294 - devproc.c:290,296
  static void
  procinit(void)
  {
- 	if(conf.nproc >= (1<<(16-QSHIFT))-1)
+ 	if(conf.nproc >= (SLOTMASK>>QSHIFT) - 1)
  		print("warning: too many procs for devproc\n");
  	addclock0link((void (*)(void))profclock, 113);	/* Relative prime to HZ */
  }

- erik

Re: [9fans] 9vx patches [was: 9vx bootimage build instructions?]

[EBo]

 On Thu, 26 May 2011 11:34:29 -0400, erik quanstrom wrote:
>>  ... it to high gives me a warning that there are to many procs for
>>  devproc...
>
> this is a bug in the warning message.
>
> ; diffy -c devproc.c
> ...
> + #define	SLOTBITS 23	/* number of bits in the slot */
> + #define	SLOTMASK	((1<<SLOTBITS)-1 << QSHIFT)
> ...

 Thanks, I have added this patch to my ebuilds.

 The system still crashes with very large numbers of procs (I think it
 is overrunning the static definition of libvx32/proc.c vxproc
 *procs[VXPROCSMAX]), but for now spawning 64 tasks is ok for
 development, but all the tests are shooting for 512.  It would be nice
 to get all the systems running consistently.  Any suggestions are
 greatly appreciated.

   EBo --

Re: [9fans] 9vx patches [was: 9vx bootimage build instructions?]

[erik quanstrom]

>  The system still crashes with very large numbers of procs (I think it
>  is overrunning the static definition of libvx32/proc.c vxproc
>  *procs[VXPROCSMAX]), but for now spawning 64 tasks is ok for
>  development, but all the tests are shooting for 512.  It would be nice
>  to get all the systems running consistently.  Any suggestions are
>  greatly appreciated.

unless someone has broken 9vx since i last pulled, the code has
that case handled.

	for (pno = 0; ; pno++) {
		if (pno == VXPROCSMAX) {
			errno = EAGAIN;
			return NULL;
		}
		if (procs[pno] == 0)
			break;
	}

if you follow vxproc_alloc calls, you'll see that each
caller checks the return value and does something reasonable.

given this,

main.c:318: 	conf.nproc = 100 + ((conf.npage*BY2PG)/MB)*5;
main.c:319: 	if(conf.nproc > 2000)
main.c:320: 		conf.nproc = 2000;

i'd suspect that the real problem is you're not giving 9vx enough
kernel memory.  try setting kernelpercent to something largeish.

but of course, i'm just guessing.  it would be helpful to have some
debugging output.

- erik

Re: [9fans] 9vx patches [was: 9vx bootimage build instructions?]

[EBo]

 On Thu, 26 May 2011 14:58:11 -0400, erik quanstrom wrote:
>>  The system still crashes with very large numbers of procs (I think
>> it
>>  is overrunning the static definition of libvx32/proc.c vxproc
>>  *procs[VXPROCSMAX]), but for now spawning 64 tasks is ok for
>>  development, but all the tests are shooting for 512.  It would be
>> nice
>>  to get all the systems running consistently.  Any suggestions are
>>  greatly appreciated.
>
> ...
>
> main.c:318: 	conf.nproc = 100 + ((conf.npage*BY2PG)/MB)*5;
> main.c:319: 	if(conf.nproc > 2000)
> main.c:320: 		conf.nproc = 2000;

 The problem here is that I had to override this test to pass in a
 limit.  On plan9 (running in kvm) it took over 3000 procs to run the 512
 tasks, and I set the memsize to 2047 (it crashed with 2048).

 The behavior is interesting.  It is moroting along and either aborts
 with a "panic: sigsegv on cpu5", a "panic: mmap address space 0", or it
 goes off into never never land (if I look at the CPU usage at this time
 it is essentially 0 where throwing 64 tasks at it causes one of the
 cores to go full tilt).

> i'd suspect that the real problem is you're not giving 9vx enough
> kernel memory.  try setting kernelpercent to something largeish.

 I've played around with setting it from 70 to 100.

> but of course, i'm just guessing.  it would be helpful to have some
> debugging output.

 I'll see what I can get you after I put out the immediate fires.
 Thanks for the suggestions.

   EBo --