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

["Devon H. O'Dell" <devon.odell@gmail.com>]

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 --
>
>
>