On Wed, Jul 02, 2003 at 03:15:51PM -0700, William Lee Irwin III wrote:
>> What complexity? Just unmap it if you can't allocate a pte_chain and
>> park it on the LRU.
On Thu, Jul 03, 2003 at 12:26:41AM +0200, Andrea Arcangeli wrote:
> the complexity in munlock to rebuild what you destroyed in mlock, that's
> linear at best (and for anonymous mappings there's no objrmap, plus
> objrmap isn't even linear but quadratic in its scan [hence the problem
> with it], though in practice it would be normally faster than the linear
> of the page scanning ;)
Computational complexity; okay.
It's not quadratic; at each munlock(), it's not necessary to do
anything more than:
for each page this mlock()'er (not _all_ mlock()'ers) maps of this thing
grab some pagewise lock
if pte_chain allocation succeeded
add pte_chain
else
/* you'll need to put anon pages in swapcache in mlock() */
unmap the page
decrement lockcount
if lockcount vanished
park it on the LRU
drop the pagewise lock
Individual mappers whose mappings are not mlock()'d add pte_chains when
faulting the things in just like before.
-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:18 EST