From e6f3de9a29518fc7b426b6a715628ccf92252267 Mon Sep 17 00:00:00 2001 From: Ingo Weinhold Date: Fri, 1 Aug 2008 00:23:56 +0000 Subject: [PATCH] Added TODO -- food for thoughts. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26711 a95241bf-73f2-0310-859d-f6bbb57e9c96 --- src/system/kernel/vm/vm.cpp | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/src/system/kernel/vm/vm.cpp b/src/system/kernel/vm/vm.cpp index 3458e9425a..f9711855b9 100644 --- a/src/system/kernel/vm/vm.cpp +++ b/src/system/kernel/vm/vm.cpp @@ -1719,6 +1719,19 @@ vm_create_anonymous_area(team_id team, const char *name, void **address, } cache->Unlock(); +// TODO: Allocating pages with the address space write locked is not a good +// idea, particularly if that's the kernel's address space. During that time the +// low memory handler will block (e.g. the block cache will try to delete +// areas). The cache backing our area has reserved the memory and thus there +// should be enough pages available (i.e. could be freed by page write/daemon), +// but this is not true for at least two reasons: +// * The pages for page directories/tables are not reserved from the available +// memory (we should do that!) and currently we don't reclaim them (and +// probably can't reclaim all of them anyway). Thus there are actually less +// pages than there should be. +// * ATM we write pages back using virtual addresses. The lower I/O layers will +// try to lock the memory, which will block, since that requires to read-lock +// the address space. vm_page_unreserve_pages(reservePages); break; }