All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tang Chen <tangchen@cn.fujitsu.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Pekka Enberg <penberg@kernel.org>,
	Jacob Shin <jacob.shin@amd.com>,
	Thomas Gleixner <tglx@linutronix.de>, Len Brown <lenb@kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>
Subject: Re: [PATCH RESEND 2/3] x86, mm: Update min_pfn_mapped in add_pfn_range_mapped().
Date: Tue, 03 Sep 2013 13:38:20 +0800	[thread overview]
Message-ID: <522575CC.6010001@cn.fujitsu.com> (raw)
In-Reply-To: <CAE9FiQXeiBZU9X7MprpBtyCQgW-u3u5m7XwvEujnvs5wHYdM4A@mail.gmail.com>

On 09/03/2013 10:48 AM, Yinghai Lu wrote:
> On Mon, Sep 2, 2013 at 6:06 PM, Tang Chen<tangchen@cn.fujitsu.com>  wrote:
>> Hi Yinghai,
>>
>> On 09/03/2013 02:41 AM, Yinghai Lu wrote:
>
>> How about change the "for (from low to high)" in init_range_memory_mapping()
>> to
>> "for_rev(from high to low)" ?
>> Then we can update min_pfn_mapped in add_pfn_range_mapped().
>>
>> And also, the outer loop is from high to low, we can change the inner loop
>> to be from high
>> to low too.
>
> No. there is other reason for doing local from low to high.
>
> kernel_physical_mapping_init() could clear some mapping near the end
> of PUG/PMD entries but not the head.

Thanks for your explanation. But sorry, I'd like to understand it more 
clearly.

Are you talking about the following code ?
	phys_pud_init()
	{
                 if (addr >= end) {
                         if (!after_bootmem &&
                             !e820_any_mapped(addr & PUD_MASK, next, 
E820_RAM) &&
                             !e820_any_mapped(addr & PUD_MASK, next, 
E820_RESERVED_KERN))
                                 set_pud(pud, __pud(0));
                         continue;
                 }
	}
It will clear the PUD/PMD out of range.


But,
init_mem_mapping()
{
     while (from high to low) {
         init_range_memory_mapping()
         {
             for (from low to high) {						/* I'm saying changing this 
loop */
                 init_memory_mapping()
                 {
                     for () {							/* Not this one */
                         kernel_physical_mapping_init();
                     }
                     add_pfn_range_mapped();
                 }
             }
         }
     }
}

I'm saying changing the outer loop in init_range_memory_mapping(), not 
the one in init_memory_mapping().
I think it is OK to call init_memory_mapping() with any order. The loop 
is out of init_memory_mapping(), right ?

In init_memory_mapping(), it is still from low to high. But when the 
kernel_physical_mapping_init() finished,
we can update min_pfn_mapped in add_pfn_range_mapped() because the outer 
loop is from high to low.

Am I missing something here ?  Please tell me.

>
>>
>> I think updating min_pfn_mapped in init_mem_mapping() is less readable. And
>> min_pfn_mapped
>> and max_pfn_mapped should be updated together.
>
> min_pfn_mapped is early local variable to control allocation in alloc_low_pages.
> put it in init_mem_mapping is more readable.
>

But add_pfn_range_mapped() is in the same file with init_mem_mapping(). 
I think
it is OK to update min_pfn_mapped in it.

Thanks.

  reply	other threads:[~2013-09-03  5:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-02 10:30 [PATCH RESEND 0/3] x86, ACPI, mm: Cleanup for {max|low|max_low}_pfn_mapped Tang Chen
2013-09-02 10:30 ` [PATCH RESEND 1/3] x86, ACPI, mm: Kill max_low_pfn_mapped Tang Chen
2013-09-02 10:30 ` [PATCH RESEND 2/3] x86, mm: Update min_pfn_mapped in add_pfn_range_mapped() Tang Chen
2013-09-02 18:41   ` Yinghai Lu
2013-09-03  1:06     ` Tang Chen
2013-09-03  2:48       ` Yinghai Lu
2013-09-03  5:38         ` Tang Chen [this message]
2013-09-03  6:34           ` Yinghai Lu
2013-09-02 10:30 ` [PATCH RESEND 3/3] x86, mm: Move max_pfn_mapped definition to init.c Tang Chen

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=522575CC.6010001@cn.fujitsu.com \
    --to=tangchen@cn.fujitsu.com \
    --cc=hpa@zytor.com \
    --cc=jacob.shin@amd.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=penberg@kernel.org \
    --cc=rjw@sisk.pl \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yinghai@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.