2010/9/12 yy :
> 2010/9/12 ron minnich :
>> 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
2010/9/12 ron minnich :
> 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 problems too. I'm current
Ah. It was 256 MB but Yiyus changed it 8 weeks ago to 64MB. Why?
ron
On Sun, Sep 12, 2010 at 11:19 AM, Russ Cox 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
>> 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
On Sun, Sep 12, 2010 at 8:44 AM, Russ Cox wrote:
> there might not be 2gb of contiguous address space to have.
> this is running inside a unix process.
Good reason :-)
What's interesting is I ran 9vx for quite some time and never hit an
issue until 8l had to load gs.
ron
On Sun Sep 12 11:45:31 EDT 2010, r...@swtch.com wrote:
> On Sun, Sep 12, 2010 at 12:59 AM, erik quanstrom
> wrote:
> >> -#define USTKTOP (0x400) /* byte just beyond
> >> user stack */
> >> +#define USTKTOP (0x800) /* byte just beyond
> >
On Sun, Sep 12, 2010 at 12:59 AM, erik quanstrom 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? what's wrong wit
On Sat, Sep 11, 2010 at 9:59 PM, erik quanstrom 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? what's wrong with
> -#define USTKTOP (0x400) /* byte just beyond
> user stack */
> +#define USTKTOP (0x800) /* byte just beyond
> user stack */
shouldn't you add a 0 to that? what's wrong with giving a process 2gb
of address space? fundamental 9vx limits
OK, the bigger user stack is committed to my vx32 at bitbucket.
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
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
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
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 000
On Sat, Sep 11, 2010 at 4:35 PM, Robert Ransom 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 under ratrace an
On Sat, 11 Sep 2010 16:07:54 -0700
ron minnich 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
> obj/iinit.8 obj/i
get some more memory? :)
On Sat, Sep 11, 2010 at 5:07 PM, ron minnich 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/gdeva
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 obj/gdevddrw
19 matches
Mail list logo
