From: Alexander Graf <agraf@suse.de>
To: Liu ping fan <kernelfans@gmail.com>
Cc: Liu Ping Fan <pingfank@linux.vnet.ibm.com>,
linuxppc-dev@lists.ozlabs.org, kvm-ppc <kvm-ppc@vger.kernel.org>,
"kvm@vger.kernel.org mailing list" <kvm@vger.kernel.org>,
Ben Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Subject: Re: [PATCH v3] powerpc: kvm: make _PAGE_NUMA take effect
Date: Mon, 14 Apr 2014 06:43:16 +0000 [thread overview]
Message-ID: <534B8384.7050500@suse.de> (raw)
In-Reply-To: <CAFgQCTsbr9_Y24upMSuOTqdO-gAVySBxW=o6uK2UKHk9=uQihw@mail.gmail.com>
On 13.04.14 04:27, Liu ping fan wrote:
> On Fri, Apr 11, 2014 at 10:03 PM, Alexander Graf <agraf@suse.de> wrote:
>> On 11.04.2014, at 13:45, Liu Ping Fan <pingfank@linux.vnet.ibm.com> wrote:
>>
>>> When we mark pte with _PAGE_NUMA we already call mmu_notifier_invalidate_range_start
>>> and mmu_notifier_invalidate_range_end, which will mark existing guest hpte
>>> entry as HPTE_V_ABSENT. Now we need to do that when we are inserting new
>>> guest hpte entries.
>> What happens when we don't? Why do we need the check? Why isn't it done implicitly? What happens when we treat a NUMA marked page as non-present? Why does it work out for us?
>>
>> Assume you have no idea what PAGE_NUMA is, but try to figure out what this patch does and whether you need to cherry-pick it into your downstream kernel. The description as is still is not very helpful for that. It doesn't even explain what really changes with this patch applied.
>>
> Yeah. what about appending the following description? Can it make
> the context clear?
> "Guest should not setup a hpte for the page whose pte is marked with
> _PAGE_NUMA, so on the host, the numa-fault mechanism can take effect
> to check whether the page is placed correctly or not."
Try to come up with a text that answers the following questions in order:
- What does _PAGE_NUMA mean?
- How does page migration with _PAGE_NUMA work?
-> Why should we not map pages when _PAGE_NUMA is set?
- Which part of what needs to be done did the previous _PAGE_NUMA
patch address?
- What's the situation without this patch?
- Which scenario does this patch fix?
Once you have a text that answers those, you should have a good patch
description :).
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Liu ping fan <kernelfans@gmail.com>
Cc: Liu Ping Fan <pingfank@linux.vnet.ibm.com>,
"kvm@vger.kernel.org mailing list" <kvm@vger.kernel.org>,
kvm-ppc <kvm-ppc@vger.kernel.org>,
Paul Mackerras <paulus@samba.org>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3] powerpc: kvm: make _PAGE_NUMA take effect
Date: Mon, 14 Apr 2014 08:43:16 +0200 [thread overview]
Message-ID: <534B8384.7050500@suse.de> (raw)
In-Reply-To: <CAFgQCTsbr9_Y24upMSuOTqdO-gAVySBxW=o6uK2UKHk9=uQihw@mail.gmail.com>
On 13.04.14 04:27, Liu ping fan wrote:
> On Fri, Apr 11, 2014 at 10:03 PM, Alexander Graf <agraf@suse.de> wrote:
>> On 11.04.2014, at 13:45, Liu Ping Fan <pingfank@linux.vnet.ibm.com> wrote:
>>
>>> When we mark pte with _PAGE_NUMA we already call mmu_notifier_invalidate_range_start
>>> and mmu_notifier_invalidate_range_end, which will mark existing guest hpte
>>> entry as HPTE_V_ABSENT. Now we need to do that when we are inserting new
>>> guest hpte entries.
>> What happens when we don't? Why do we need the check? Why isn't it done implicitly? What happens when we treat a NUMA marked page as non-present? Why does it work out for us?
>>
>> Assume you have no idea what PAGE_NUMA is, but try to figure out what this patch does and whether you need to cherry-pick it into your downstream kernel. The description as is still is not very helpful for that. It doesn't even explain what really changes with this patch applied.
>>
> Yeah. what about appending the following description? Can it make
> the context clear?
> "Guest should not setup a hpte for the page whose pte is marked with
> _PAGE_NUMA, so on the host, the numa-fault mechanism can take effect
> to check whether the page is placed correctly or not."
Try to come up with a text that answers the following questions in order:
- What does _PAGE_NUMA mean?
- How does page migration with _PAGE_NUMA work?
-> Why should we not map pages when _PAGE_NUMA is set?
- Which part of what needs to be done did the previous _PAGE_NUMA
patch address?
- What's the situation without this patch?
- Which scenario does this patch fix?
Once you have a text that answers those, you should have a good patch
description :).
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Liu ping fan <kernelfans@gmail.com>
Cc: Liu Ping Fan <pingfank@linux.vnet.ibm.com>,
linuxppc-dev@lists.ozlabs.org, kvm-ppc <kvm-ppc@vger.kernel.org>,
"kvm@vger.kernel.org mailing list" <kvm@vger.kernel.org>,
Ben Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Subject: Re: [PATCH v3] powerpc: kvm: make _PAGE_NUMA take effect
Date: Mon, 14 Apr 2014 08:43:16 +0200 [thread overview]
Message-ID: <534B8384.7050500@suse.de> (raw)
In-Reply-To: <CAFgQCTsbr9_Y24upMSuOTqdO-gAVySBxW=o6uK2UKHk9=uQihw@mail.gmail.com>
On 13.04.14 04:27, Liu ping fan wrote:
> On Fri, Apr 11, 2014 at 10:03 PM, Alexander Graf <agraf@suse.de> wrote:
>> On 11.04.2014, at 13:45, Liu Ping Fan <pingfank@linux.vnet.ibm.com> wrote:
>>
>>> When we mark pte with _PAGE_NUMA we already call mmu_notifier_invalidate_range_start
>>> and mmu_notifier_invalidate_range_end, which will mark existing guest hpte
>>> entry as HPTE_V_ABSENT. Now we need to do that when we are inserting new
>>> guest hpte entries.
>> What happens when we don't? Why do we need the check? Why isn't it done implicitly? What happens when we treat a NUMA marked page as non-present? Why does it work out for us?
>>
>> Assume you have no idea what PAGE_NUMA is, but try to figure out what this patch does and whether you need to cherry-pick it into your downstream kernel. The description as is still is not very helpful for that. It doesn't even explain what really changes with this patch applied.
>>
> Yeah. what about appending the following description? Can it make
> the context clear?
> "Guest should not setup a hpte for the page whose pte is marked with
> _PAGE_NUMA, so on the host, the numa-fault mechanism can take effect
> to check whether the page is placed correctly or not."
Try to come up with a text that answers the following questions in order:
- What does _PAGE_NUMA mean?
- How does page migration with _PAGE_NUMA work?
-> Why should we not map pages when _PAGE_NUMA is set?
- Which part of what needs to be done did the previous _PAGE_NUMA
patch address?
- What's the situation without this patch?
- Which scenario does this patch fix?
Once you have a text that answers those, you should have a good patch
description :).
Alex
next prev parent reply other threads:[~2014-04-14 6:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-11 11:45 [PATCH v3] powerpc: kvm: make _PAGE_NUMA take effect Liu Ping Fan
2014-04-11 11:45 ` Liu Ping Fan
2014-04-11 11:45 ` Liu Ping Fan
2014-04-11 14:03 ` Alexander Graf
2014-04-11 14:03 ` Alexander Graf
2014-04-11 14:03 ` Alexander Graf
2014-04-13 2:27 ` Liu ping fan
2014-04-13 2:27 ` Liu ping fan
2014-04-13 2:27 ` Liu ping fan
2014-04-14 6:43 ` Alexander Graf [this message]
2014-04-14 6:43 ` Alexander Graf
2014-04-14 6:43 ` Alexander Graf
2014-04-14 8:08 ` liu ping fan
2014-04-14 8:08 ` liu ping fan
2014-04-14 8:08 ` liu ping fan
2014-04-14 9:01 ` Alexander Graf
2014-04-14 9:01 ` Alexander Graf
2014-04-14 9:01 ` Alexander Graf
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=534B8384.7050500@suse.de \
--to=agraf@suse.de \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=kernelfans@gmail.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
--cc=pingfank@linux.vnet.ibm.com \
/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.