Re: [PATCH v3 1/3] deactivate invalidated pages

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Johannes Weiner
Date: Monday, November 29, 2010 - 10:22 pm

On Tue, Nov 30, 2010 at 12:23:19AM +0900, Minchan Kim wrote:

[...]


The wording is a bit confusing, I find.  It sounds a bit like the
flusher's chance is increased by moving it to the inactive list in the
first place, but the key is that it is moved to the head instead of,
what one would expect, the tail of the list.  How about:

	If the page can not be invalidated, it is moved to the
	inactive list to speed up its reclaim.  It is moved to the
	head of the list, rather than the tail, to give the flusher
	threads some time to write it out, as this is much more
	effective than the single-page writeout from reclaim.


Do you insist on the underscores? :)


Why is that?  Unless I missed something, the only thing that needs
protection is the per-cpu pagevec reference the only user of this
function passes in.  But this should be the caller's concern and is
not really a requirement of this function per-se, is it?


More underscores!


How about:

/**
 * lru_deactivate_page - forcefully deactivate a page
 * @page: page to deactivate
 *
 * This function hints the VM that @page is a good reclaim candidate,
 * for example if its invalidation fails due to the page being dirty
 * or under writeback.
 */


I would love that lru_ prefix for most of the API in this file.  In
fact, the file should probably be called lru.c.  But for now, can you
keep the naming consistent and call it deactivate_page?


[...]


This would also be less confusing if it would say

	Move it to the head of the inactive LRU (rather than the tail)
	for using [...]

But I am not sure that this detail is interesting at this point.  It
would be more interesting to name the reasons for why the page is
moved to the inactive list in the first place:

	If the page is dirty or under writeback, we can not invalidate
	it now.  But we assume that attempted invalidation is a hint
	that the page is no longer of interest and try to speed up its
	reclaim.


	Hannes
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH v3 0/3] f/madivse(DONTNEED) support, Minchan Kim, (Mon Nov 29, 8:23 am)
[PATCH v3 1/3] deactivate invalidated pages, Minchan Kim, (Mon Nov 29, 8:23 am)
[PATCH 2/3] Reclaim invalidated page ASAP, Minchan Kim, (Mon Nov 29, 8:23 am)
Re: [PATCH 2/3] Reclaim invalidated page ASAP, Mel Gorman, (Mon Nov 29, 9:57 am)
Re: [PATCH 2/3] Reclaim invalidated page ASAP, Minchan Kim, (Mon Nov 29, 3:41 pm)
Re: [PATCH v3 1/3] deactivate invalidated pages, KOSAKI Motohiro, (Mon Nov 29, 6:01 pm)
Re: [PATCH 2/3] Reclaim invalidated page ASAP, KOSAKI Motohiro, (Mon Nov 29, 6:10 pm)
Re: [PATCH v3 1/3] deactivate invalidated pages, Johannes Weiner, (Mon Nov 29, 10:22 pm)
Re: [PATCH v3 1/3] deactivate invalidated pages, Minchan Kim, (Mon Nov 29, 11:18 pm)
Re: [PATCH 2/3] Reclaim invalidated page ASAP, Mel Gorman, (Tue Nov 30, 2:16 am)
Re: [PATCH 2/3] Reclaim invalidated page ASAP, Mel Gorman, (Tue Nov 30, 2:18 am)
Re: [PATCH 2/3] Reclaim invalidated page ASAP, Johannes Weiner, (Tue Nov 30, 4:20 am)
Re: [PATCH 2/3] Reclaim invalidated page ASAP, Minchan Kim, (Tue Nov 30, 7:01 am)
Re: [PATCH 2/3] Reclaim invalidated page ASAP, Minchan Kim, (Tue Nov 30, 7:03 am)
Re: [PATCH 2/3] Reclaim invalidated page ASAP, Minchan Kim, (Tue Nov 30, 7:04 am)
Re: [PATCH 2/3] Reclaim invalidated page ASAP, Ben Gamari, (Tue Nov 30, 7:11 am)