linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Oleg Nesterov <oleg@tv-sign.ru>, akpm@osdl.org
Cc: linux-mm@kvack.org
Subject: Re: Q: shrink_cache() vs release_pages() page->lru management
Date: Mon, 17 Jan 2005 07:17:23 -0200	[thread overview]
Message-ID: <20050117091723.GB18785@logos.cnet> (raw)
In-Reply-To: <41EAA59C.B6987930@tv-sign.ru>

Hi Oleg,

On Sun, Jan 16, 2005 at 08:34:20PM +0300, Oleg Nesterov wrote:
> Another attempt, message was truncated...
> 
> shrink_cache:
> 	if (get_page_testone(page)) {
> 		__put_page(page);
> 		SetPageLRU(page);
> 		list_add(&page->lru, &zone->inactive_list);
> 		continue;
> 	}
> 
> Is it really necessary to re-add the page to inactive_list?
> 
> It seems to me that shrink_cache() can just do:
> 
> 	if (get_page_testone(page)) {
> 		__put_page(page);
> 		--zone->nr_inactive;
> 		continue;
> 	}
> 
> When the __page_cache_release (or whatever) takes zone->lru_lock
> it must check PG_lru before del_page_from_lru().
> 
> The same question applies to refill_inactive_zone().

Yes it seems OK to not re-add the page to LRU if "zero" page (-1 count) 
is found, since all callers which set page count to zero (release_pages and 
__page_cache_release()) are going to remove the page from LRU and most likely 
free it anyway. 

The original code is just being safe I guess...

/*
 * This path almost never happens for VM activity - pages are normally
 * freed via pagevecs.  But it gets used by networking.
 */
void fastcall __page_cache_release(struct page *page)
{
        unsigned long flags;
        struct zone *zone = page_zone(page);

        spin_lock_irqsave(&zone->lru_lock, flags);
        if (TestClearPageLRU(page))
                del_page_from_lru(zone, page);
        if (page_count(page) != 0)
                page = NULL;
        spin_unlock_irqrestore(&zone->lru_lock, flags);
        if (page)
                free_hot_page(page);
}

Looking at __page_cache_release() it handles the case where another reference count
is grabbed in the meantime (see the page_count(page) != 0 check).

Now that makes me wonder: in what case page_count(page) != 0 can happen 
during __page_cache_release()? Any user who has a direct pointer to the page 
could do that - pagecache pages have already been removed from the radix 
tree and can't be reached through it at this point in time.

And when that happens, does the reference grabber has to re-add the page to LRU 
since it has just been removed from LRU by __page_cache_release ?  Looks cheesy.

Andrew?


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

      reply	other threads:[~2005-01-17  9:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-16 17:21 Oleg Nesterov
2005-01-16 17:34 ` Oleg Nesterov
2005-01-17  9:17   ` Marcelo Tosatti [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050117091723.GB18785@logos.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=akpm@osdl.org \
    --cc=linux-mm@kvack.org \
    --cc=oleg@tv-sign.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox