From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <2cf9720b82e19cf7af8332c8ebddeb76@felloff.net>
Date: Sun,  2 Mar 2014 02:21:08 +0100
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
In-Reply-To: <CAOw7k5gsC5JVQnq286yOyYpJzDvqGV9mBwq9au0-Wm1P3DLXqA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] imagereclaim()
Topicbox-Message-UUID: c08d7d80-ead8-11e9-9d60-3106f5b1d025

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* instead of giving up the search.

so duppage() appears atomic on 9front, but on labs, a process
already commited to use that page in lookpage() will get a
uncached page after the lock() succeeds and miss the (potential)
new page put in by duppage().

but what you describe is possible with pio() in general.

a process decides to demand load a page in pio() when lookpage()
doesnt return a cached page.

if multiple processes compete on loading the same page while its not in
the cache, they will indeed do so. in the case that they share the
segment, it will get deduplicated after the load and the page of the
first process finishing the load wins, the other pages will be put back
on the freelist (uncached). if they use distinct segments,
they (the processes) will all cache ther pages in the image and the
image will end up with multiple pages caching the same disk address
of the file.

it would be nice if the SP9SSS could speak out in detail on how they
do page caching differently than classic plan9.

--
cinap