All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Michal Hocko <mhocko@kernel.org>,
	"Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Minchan Kim <minchan@kernel.org>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: isolate_lru_page on !head pages
Date: Tue, 22 Dec 2015 16:47:39 +0100	[thread overview]
Message-ID: <5679709B.8030908@suse.cz> (raw)
In-Reply-To: <20151215165943.GB27880@dhcp22.suse.cz>

On 12/15/2015 05:59 PM, Michal Hocko wrote:
>>
>> head page is what linked into LRU, but not nessesary the way we obtain the
>> page to check. If we check PageLRU(pte_page(*pte)) it should produce the
>> right result.
>
> I am not following you here. Any pfn walk could get to a tail page and
> if we happen to do e.g. isolate_lru_page we have to remember that we
> should always treat compound page differently. This is subtle.

I think the problem is that isolate_lru_page() is not the only reason 
for calling PageLRU(). And the other use cases have different 
expectations, to either way (PF_ANY or PF_HEAD) you pick for PageLRU(), 
somebody will have to be careful. IMHO usually it's pfn scanners who 
have to be careful for many reasons...

> Anyway I
> am far from understading other parts of the refcount rework so I will
> spend time studying the code as soon as the time permits. In the
> meantime I agree that VM_BUG_ON_PAGE(PageTail(page), page) would be
> useful to catch all the fallouts.

+1

--
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:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Michal Hocko <mhocko@kernel.org>,
	"Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Minchan Kim <minchan@kernel.org>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: isolate_lru_page on !head pages
Date: Tue, 22 Dec 2015 16:47:39 +0100	[thread overview]
Message-ID: <5679709B.8030908@suse.cz> (raw)
In-Reply-To: <20151215165943.GB27880@dhcp22.suse.cz>

On 12/15/2015 05:59 PM, Michal Hocko wrote:
>>
>> head page is what linked into LRU, but not nessesary the way we obtain the
>> page to check. If we check PageLRU(pte_page(*pte)) it should produce the
>> right result.
>
> I am not following you here. Any pfn walk could get to a tail page and
> if we happen to do e.g. isolate_lru_page we have to remember that we
> should always treat compound page differently. This is subtle.

I think the problem is that isolate_lru_page() is not the only reason 
for calling PageLRU(). And the other use cases have different 
expectations, to either way (PF_ANY or PF_HEAD) you pick for PageLRU(), 
somebody will have to be careful. IMHO usually it's pfn scanners who 
have to be careful for many reasons...

> Anyway I
> am far from understading other parts of the refcount rework so I will
> spend time studying the code as soon as the time permits. In the
> meantime I agree that VM_BUG_ON_PAGE(PageTail(page), page) would be
> useful to catch all the fallouts.

+1


  reply	other threads:[~2015-12-22 15:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-09 13:02 isolate_lru_page on !head pages Michal Hocko
2015-12-09 13:02 ` Michal Hocko
2015-12-14 12:04 ` Kirill A. Shutemov
2015-12-14 12:04   ` Kirill A. Shutemov
2015-12-15  8:52   ` Michal Hocko
2015-12-15  8:52     ` Michal Hocko
2015-12-15 12:03     ` Kirill A. Shutemov
2015-12-15 12:03       ` Kirill A. Shutemov
2015-12-15 16:59       ` Michal Hocko
2015-12-15 16:59         ` Michal Hocko
2015-12-22 15:47         ` Vlastimil Babka [this message]
2015-12-22 15:47           ` Vlastimil Babka

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=5679709B.8030908@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.