2010/9/12 yy yiyu@gmail.com:
2010/9/12 ron minnich rminn...@gmail.com:
Ah. It was 256 MB but Yiyus changed it 8 weeks ago to 64MB. Why?
Sorry about that. It was after updating all the a/ files from the .ed
scripts. It looks like I did not pay enough attention to mem.ed. There
were other
On Sat, Sep 11, 2010 at 9:59 PM, erik quanstrom quans...@quanstro.net wrote:
-#define USTKTOP (0x400) /* byte just beyond
user stack */
+#define USTKTOP (0x800) /* byte just beyond
user stack */
shouldn't you add a 0 to that?
On Sun, Sep 12, 2010 at 12:59 AM, erik quanstrom quans...@quanstro.net wrote:
-#define USTKTOP (0x400) /* byte just beyond
user stack */
+#define USTKTOP (0x800) /* byte just beyond
user stack */
shouldn't you add a 0 to that?
On Sun Sep 12 11:45:31 EDT 2010, r...@swtch.com wrote:
On Sun, Sep 12, 2010 at 12:59 AM, erik quanstrom quans...@quanstro.net
wrote:
-#define USTKTOP (0x400) /* byte just beyond
user stack */
+#define USTKTOP (0x800) /* byte just
another reason for the low size was so that it was easier
to keep multiple processes mapped at the same time,
to reduce context switch latency.
that makes sense. unfortunately, this means that any
process that uses significant memory on plan 9 needs
to be re-checked for 9vx. even 100mb is
On Sun, Sep 12, 2010 at 11:19 AM, Russ Cox r...@swtch.com wrote:
(and actually i thought the 9vx limit was 256 MB;
maybe ron cranked it down.)
I don't think so but I'll dig around.
ron
2010/9/12 ron minnich rminn...@gmail.com:
Ah. It was 256 MB but Yiyus changed it 8 weeks ago to 64MB. Why?
Sorry about that. It was after updating all the a/ files from the .ed
scripts. It looks like I did not pay enough attention to mem.ed. There
were other changes that could be causing
any good ideas here? I'm running with 9vx -m 1024. Kind of hard to
believe I'm out.
mk gs
pcc -o 8.out obj/gs.8 obj/adler32.8 obj/compress.8 obj/crc32.8
obj/deflate.8 obj/dscparse.8 obj/gconfig.8 obj/gdevabuf.8
obj/gdevbbox.8 obj/gdevbj10.8 obj/gdevcd8.8 obj/gdevcdj.8
obj/gdevdbit.8
On Sat, 11 Sep 2010 16:07:54 -0700
ron minnich rminn...@gmail.com wrote:
any good ideas here? I'm running with 9vx -m 1024. Kind of hard to
believe I'm out.
mk gs
pcc -o 8.out obj/gs.8 obj/adler32.8 obj/compress.8 obj/crc32.8
obj/deflate.8 obj/dscparse.8 obj/gconfig.8 obj/gdevabuf.8
On Sat, Sep 11, 2010 at 4:35 PM, Robert Ransom rransom.8...@gmail.com wrote:
BUGS
There is a large but finite limit on the size of an argment
list, typically around 409,600 bytes. The kernel constant
TSTKSIZ controls this.
...
Robert Ransom
no, I'm running
This operating system is so much fun it's unfair at times.
term% grep Brk /dev/text | grep 8l
4684 8l Brk 0xdeba 0003ea58 = 0
0x11d2943ddb0c6c28 0x11d2943ddb0ccdd0
4684 8l Brk 0xdeba 000570f8 00017494 1fa8 = 0
0x11d2943ded6477a8 0x11d2943ded64cd98
4684 8l Brk 0xdeba
the problematic code is at /sys/src/9/port/segment.c:483,491
for(i = 0; i NSEG; i++) {
ns = up-seg[i];
if(ns == 0 || ns == s)
continue;
if(newtop = ns-base newtop ns-top) {
qunlock(s-lk);
Actually it's really simple. Stack in 9vx begins at 48 MB. A bit small
for compiling gs I suppose :-)
I'll see how to grow it.
ron
diff -r 6ab31397d4b9 src/9vx/a/mem.h
--- a/src/9vx/a/mem.h Sat Sep 11 23:09:14 2010 +0200
+++ b/src/9vx/a/mem.h Sat Sep 11 19:31:19 2010 -0700
@@ -41,7 +41,7 @@
#defineVMAPSIZE(0x1000-VPTSIZE-KMAPSIZE)
#defineUZERO 0 /* base of user
OK, the bigger user stack is committed to my vx32 at bitbucket.
ron
15 matches
Mail list logo
