Re: [9fans] paging

Re: [9fans] paging

[jmk]

On Mon, 8 Jan 2001 forsyth@caldo.demon.co.uk wrote:
> - it did not happen with 2nd edition on any platform

but lots of other really bad things did.

Re: [9fans] paging

[forsyth]

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

that's true enough.


[-- Attachment #2: Type: message/rfc822, Size: 1388 bytes --]

To: cse.psu.edu!9fans
Subject: Re: [9fans] paging
Date: Mon, 8 Jan 2001 10:17:12 -0500
Message-ID: <20010108151714.6E93B19A08@mail.cse.psu.edu>

On Mon, 8 Jan 2001 forsyth@caldo.demon.co.uk wrote:
> - it did not happen with 2nd edition on any platform

but lots of other really bad things did.

Re: [9fans] paging

[Alexander Viro]

On Mon, 8 Jan 2001 forsyth@caldo.demon.co.uk wrote:

> - it can happen with paging to local disc
> - it CAN happen when paging over an ethernet to a file from a file server
> - it can lead to process hangs or traps; rio and acme are common targets
> - to judge from last-write times on the paging files, the problem is caused by paging
> - uniprocessors are affected
> - we most easily provoke it using charon to read huge pages on slashdot(!)
> - rio and acme (and emu) use rfork(RFMEM).  coincidence?
> - it did not happen with 2nd edition on any platform
> 
> at one point it seemed that it might be related to shared text/memory, because
> it once left a particular program corrupted but enough elsewhere was
> running that we could look at it (normally it damages enough of the interface
> that it is hard to debug).  i'm still not convinced.

	Just a gut feeling: procflushseg() and stuff triggered by it.
Check for situations when process gets created in the middle of procflushseg().
I didn't look deep enough, but it just screams "races will grow here, even
if there is none right now"...

Re: [9fans] paging

[forsyth]

>>I suspect something in the x86 memory management code,
>>although presotto says the carreras had similar problems.
>>I spent a day this summer trying to find anything, but
>>like everyone else came up empty handed.  

oh good (in a way); i was beginning to feel incompetent.

from our observations:

- it can happen with paging to local disc
- it CAN happen when paging over an ethernet to a file from a file server
- it can lead to process hangs or traps; rio and acme are common targets
- to judge from last-write times on the paging files, the problem is caused by paging
- uniprocessors are affected
- we most easily provoke it using charon to read huge pages on slashdot(!)
- rio and acme (and emu) use rfork(RFMEM).  coincidence?
- it did not happen with 2nd edition on any platform

at one point it seemed that it might be related to shared text/memory, because
it once left a particular program corrupted but enough elsewhere was
running that we could look at it (normally it damages enough of the interface
that it is hard to debug).  i'm still not convinced.