Thread (29 messages) 29 messages, 4 authors, 2006-09-15

Re: [patch 3/9] Guest page hinting: volatile page cache.

From: Dave Hansen <hidden>
Date: 2006-09-01 18:42:05
Also in: lkml

On Fri, 2006-09-01 at 20:31 +0200, Martin Schwidefsky wrote:
On Fri, 2006-09-01 at 11:23 -0700, Dave Hansen wrote:
quoted
OK, and there's no other workable solution to exclude each other from
running at the same time than a bit in page->flags?

It seems like that hashed lock (or lock in mem_map[]) we were talking
about earlier might be applicable here, too.
The indication which page has already been removed from the page cache
by a discard fault is by definition per-page.
Right.  So having a single bit that was set and cleared wouldn't work
because it could get interpreted incorrectly for multiple pages.  But,
what about a lock?
The situation is different
compared to the one with PG_state_change which is used to protect
critical sections. After the cpu left the critical section the bit can
be clear again. The discard bit cannot be cleared until the page really
has been freed.
While something like the following wouldn't be scalable, it would
functionally work, right?

+static void __page_discard(struct page *page)
+{
+	spin_lock(discard_lock);
...
+	spin_unlock(discard_lock);
+}

+void __delete_from_swap_cache(struct page *page)
+{
+	spin_lock(discard_lock);
...
+	spin_unlock(discard_lock);
+}

+void __remove_from_page_cache(struct page *page)
+{
+	spin_lock(discard_lock);
...
+	spin_unlock(discard_lock);
+}


-- Dave
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help