On Sun Mar 2 18:01:39 EST 2014, al...@pbrane.org wrote:
> Charles Forsyth once said:
> > I also ripped out all the swap stuff. Either I'm on a machine with at last
> > a Gb or two of RAM, or it's embedded
> > and there's no paging disk, or both.
>
> What do you do when you're out of memory? Pani
Charles Forsyth once said:
> I also ripped out all the swap stuff. Either I'm on a machine with at last
> a Gb or two of RAM, or it's embedded
> and there's no paging disk, or both.
What do you do when you're out of memory? Panic?
Do you still have something like the kickpager in
nix?
Anthony
On 2 March 2014 18:46, wrote:
> you'r right. the smartness of duppage() isnt really neccesary. we
> can just leave the cache alone. when memory is low, newpage() will
> uncache pages for us.
>
I also ripped out all the swap stuff. Either I'm on a machine with at last
a Gb or two of RAM, or it's
you'r right. the smartness of duppage() isnt really neccesary. we
can just leave the cache alone. when memory is low, newpage() will
uncache pages for us.
fixfault():
...
lkp = *pg;
lock(lkp);
if(lkp->ref == 0)
On 2 March 2014 03:55, wrote:
> checked nix/port/page.c. your duppage() is wrong.
It isn't needed at all. When a cached page is written, it's trying hard to
replace the page in the cache by a new copy,
to return the previously cached page. Instead, I copy the cached page and
return the copy, wh
nono. i ment to suggest that you put a print/asser after the whole if
block in case you do not belive what i said could can happen. and
once convinced, change the p->ref == 0 to p->ref != 1 and fix
fixfault() :-)
--
cinap
On Sat Mar 1 22:56:25 EST 2014, cinap_len...@felloff.net wrote:
> checked nix/port/page.c. your duppage() is wrong.
>
> /* don't dup pages with no image */
> if(p->ref == 0 || p->image == nil || p->image->notext)
> return 0;
>
> /*
>* normal lock ordering
checked nix/port/page.c. your duppage() is wrong.
/* don't dup pages with no image */
if(p->ref == 0 || p->image == nil || p->image->notext)
return 0;
/*
* normal lock ordering is to call
* lock(&pga) before lock(p).
* To avoid
odd coincidence. this just happened:
no panlic:o cpou0:p cpu0:s de
adlock/abandoned lock 0xf21547f0 key 0xf215483c pc
0xf01ce2bd proc 1893 held by pc 0xf01c
acid; src(0xf01ce2bd)
/sys/src/nix/port/page.c:552
547for(f = pghash(daddr); f; f = f
i checked the code on sources again and found the issue.
the lookpage() in 9front is different. we lock the page from
the image cache hash chain and check if the page is still
cached and for the right disk address under the lock.
but if it changed or got uncached by duppage(), we unlock
and *retry
On 1 March 2014 23:05, wrote:
> how is this possible? the old page is locked during the call
> to duppage(). so duppage() will not run concurrently on the
> same page.
>
there's a race to decide whether to do it, and what happens to the page
once it has. it reaches back into the page load code.
On Sat Mar 1 18:07:04 EST 2014, cinap_len...@felloff.net wrote:
> how is this possible? the old page is locked during the call
> to duppage(). so duppage() will not run concurrently on the
> same page.
what happens if !canlock(&pga) is true and ∴ p is unlocked.
- erik
On 1 March 2014 22:22, wrote:
> or are
> you refering to a different problem?
>
duppage isn't necessary. neither, come to that, is the page hash table.
i do without them both, and without a few other things, like the pager.
how is this possible? the old page is locked during the call
to duppage(). so duppage() will not run concurrently on the
same page.
--
cinap
On Sat Mar 1 17:24:03 EST 2014, cinap_len...@felloff.net wrote:
> not sure what you mean. the page passed to duppage() is not
> on the freelist. and the new page duppage() allocates and
> caches is chained on the tail as far as i can see. so
> the invariant required by imagereclaim() holds. or are
not sure what you mean. the page passed to duppage() is not
on the freelist. and the new page duppage() allocates and
caches is chained on the tail as far as i can see. so
the invariant required by imagereclaim() holds. or are
you refering to a different problem?
--
cinap
On Sat Mar 1 16:51:29 EST 2014, cinap_len...@felloff.net wrote:
> the imagereclaim algorithm is wrong.
yes. and so is duppage(). charles has some ideas here.
- erik
the imagereclaim algorithm is wrong.
/*
* All the pages with images backing them are at the
* end of the list (see putpage) so start there and work
* backward.
*/
for(p = palloc.tail; p && p->image && n<1000; p = p->prev) {
if(p->
18 matches
Mail list logo
