Re: [Patch 8/8] kexec: allow to shrink reserved memory

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[Amerigo Wang]

Eric W. Biederman wrote:
> Amerigo Wang <amwang@redhat.com> writes:
>
>   
>> This patch implements shrinking the reserved memory for crash kernel,
>> if it is more than enough.
>>
>> For example, if you have already reserved 128M, now you just want 100M,
>> you can do:
>>
>> # echo $((100*1024*1024)) > /sys/kernel/kexec_crash_size
>>     
>
> Getting closer (comments inline)
>
> Semantically this patch is non-contriversial and pretty
> simple, but still needs a fair amount of review.  Can
> you put this patch at the front of your patch set.
>
>   

Sure, I will do it when I resend them next time.

I add mm people into Cc.
>> Index: linux-2.6/kernel/kexec.c
>> ===================================================================
>> --- linux-2.6.orig/kernel/kexec.c
>> +++ linux-2.6/kernel/kexec.c
>> @@ -1083,6 +1083,76 @@ void crash_kexec(struct pt_regs *regs)
>>  	}
>>  }
>>  
>> +int kexec_crash_kernel_loaded(void)
>> +{
>> +	int ret;
>> +	if (!mutex_trylock(&kexec_mutex))
>> +		return 1;
>>     
>
> We don't need trylock on this code path 
>   

OK.

>   
>> +	ret = kexec_crash_image != NULL;
>> +	mutex_unlock(&kexec_mutex);
>> +	return ret;
>> +}
>> +
>> +size_t get_crash_memory_size(void)
>> +{
>> +	size_t size;
>> +	if (!mutex_trylock(&kexec_mutex))
>> +		return 1;
>>     
>
> We don't need trylock on this code path 
>
>   

Hmm, crashk_res is a global struct, so other process can also
change it... but currently no process does that, right?

>> +	size = crashk_res.end - crashk_res.start + 1;
>> +	mutex_unlock(&kexec_mutex);
>> +	return size;
>> +}
>> +
>> +int shrink_crash_memory(unsigned long new_size)
>> +{
>> +	struct page **pages;
>> +	int ret = 0;
>> +	int  npages, i;
>> +	unsigned long addr;
>> +	unsigned long start, end;
>> +	void *vaddr;
>> +
>> +	if (!mutex_trylock(&kexec_mutex))
>> +		return -EBUSY;
>>     
>
> We don't need trylock on this code path 
>
> We are missing the check to see if the crash_kernel is loaded
> under this lock instance. So I please move the kexec_crash_image != NULL
> test inline here and kill the kexec_crash_kernel_loaded function.
>   

Ok, no problem.

>   
>> +	start = crashk_res.start;
>> +	end = crashk_res.end;
>> +
>> +	if (new_size >= end - start + 1) {
>> +		ret = -EINVAL;
>> +		if (new_size == end - start + 1)
>> +			ret = 0;
>> +		goto unlock;
>> +	}
>> +
>> +	start = roundup(start, PAGE_SIZE);
>> +	end = roundup(start + new_size, PAGE_SIZE) - 1;
>> +	npages = (end + 1 - start ) / PAGE_SIZE;
>> +
>> +	pages = kmalloc(sizeof(struct page *) * npages, GFP_KERNEL);
>> +	if (!pages) {
>> +		ret = -ENOMEM;
>> +		goto unlock;
>> +	}
>> +	for (i = 0; i < npages; i++) {
>> +		addr = end + 1 + i * PAGE_SIZE;
>> +		pages[i] = virt_to_page(addr);
>> +	}
>> +
>> +	vaddr = vm_map_ram(pages, npages, 0, PAGE_KERNEL);
>>     
>
> This is the wrong kernel call to use.  I expect this needs to look
> like a memory hotplug event.  This does not put the pages into the
> free page pool.
>   

Well, I also wanted to use an memory-hotplug API, but that will make the 
code depend on memory-hotplug, which certainly is not what we want...

I checked the mm code, actually what I need is an API which is similar 
to add_active_range(), but add_active_range() can't be used here since 
it is marked as "__init".

Do we have that kind of API in mm? I can't find one.

Thanks!


--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[Eric W. Biederman]

Amerigo Wang <amwang@redhat.com> writes:

> Eric W. Biederman wrote:
>> Amerigo Wang <amwang@redhat.com> writes:
>>
>>   
>>> This patch implements shrinking the reserved memory for crash kernel,
>>> if it is more than enough.
>>>
>>> For example, if you have already reserved 128M, now you just want 100M,
>>> you can do:
>>>
>>> # echo $((100*1024*1024)) > /sys/kernel/kexec_crash_size
>>>     
>>
>> Getting closer (comments inline)
>>
>> Semantically this patch is non-contriversial and pretty
>> simple, but still needs a fair amount of review.  Can
>> you put this patch at the front of your patch set.
>>
>>   
>
> Sure, I will do it when I resend them next time.
>
> I add mm people into Cc.
>>> Index: linux-2.6/kernel/kexec.c
>>> ===================================================================
>>> --- linux-2.6.orig/kernel/kexec.c
>>> +++ linux-2.6/kernel/kexec.c
>>> @@ -1083,6 +1083,76 @@ void crash_kexec(struct pt_regs *regs)
>>>  	}
>>>  }
>>>  +int kexec_crash_kernel_loaded(void)
>>> +{
>>> +	int ret;
>>> +	if (!mutex_trylock(&kexec_mutex))
>>> +		return 1;
>>>     
>>
>> We don't need trylock on this code path   
>
> OK.
>
>>   
>>> +	ret = kexec_crash_image != NULL;
>>> +	mutex_unlock(&kexec_mutex);
>>> +	return ret;
>>> +}
>>> +
>>> +size_t get_crash_memory_size(void)
>>> +{
>>> +	size_t size;
>>> +	if (!mutex_trylock(&kexec_mutex))
>>> +		return 1;
>>>     
>>
>> We don't need trylock on this code path 
>>
>>   
>
> Hmm, crashk_res is a global struct, so other process can also
> change it... but currently no process does that, right?
>

We still need the lock.  Just doing trylock doesn't instead
of just sleeping doesn't seem to make any sense on these
code paths.

>>> +	size = crashk_res.end - crashk_res.start + 1;
>>> +	mutex_unlock(&kexec_mutex);
>>> +	return size;
>>> +}
>>> +
>>> +int shrink_crash_memory(unsigned long new_size)
>>> +{
>>> +	struct page **pages;
>>> +	int ret = 0;
>>> +	int  npages, i;
>>> +	unsigned long addr;
>>> +	unsigned long start, end;
>>> +	void *vaddr;
>>> +
>>> +	if (!mutex_trylock(&kexec_mutex))
>>> +		return -EBUSY;
>>>     
>>
>> We don't need trylock on this code path 
>>
>> We are missing the check to see if the crash_kernel is loaded
>> under this lock instance. So I please move the kexec_crash_image != NULL
>> test inline here and kill the kexec_crash_kernel_loaded function.
>>   
>
> Ok, no problem.
>
>>   
>>> +	start = crashk_res.start;
>>> +	end = crashk_res.end;
>>> +
>>> +	if (new_size >= end - start + 1) {
>>> +		ret = -EINVAL;
>>> +		if (new_size == end - start + 1)
>>> +			ret = 0;
>>> +		goto unlock;
>>> +	}
>>> +
>>> +	start = roundup(start, PAGE_SIZE);
>>> +	end = roundup(start + new_size, PAGE_SIZE) - 1;
>>> +	npages = (end + 1 - start ) / PAGE_SIZE;
>>> +
>>> +	pages = kmalloc(sizeof(struct page *) * npages, GFP_KERNEL);
>>> +	if (!pages) {
>>> +		ret = -ENOMEM;
>>> +		goto unlock;
>>> +	}
>>> +	for (i = 0; i < npages; i++) {
>>> +		addr = end + 1 + i * PAGE_SIZE;
>>> +		pages[i] = virt_to_page(addr);
>>> +	}
>>> +
>>> +	vaddr = vm_map_ram(pages, npages, 0, PAGE_KERNEL);
>>>     
>>
>> This is the wrong kernel call to use.  I expect this needs to look
>> like a memory hotplug event.  This does not put the pages into the
>> free page pool.
>>   
>
> Well, I also wanted to use an memory-hotplug API, but that will make the code
> depend on memory-hotplug, which certainly is not what we want...
>
> I checked the mm code, actually what I need is an API which is similar to
> add_active_range(), but add_active_range() can't be used here since it is marked
> as "__init".
>
> Do we have that kind of API in mm? I can't find one.

Perhaps we will need to remove __init from add_active_range.  I know the logic
but I'm not up to speed on the mm pieces at the moment.

Eric

--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[Amerigo Wang]

Eric W. Biederman wrote:
> Amerigo Wang <amwang@redhat.com> writes:
>
>   
>>>   
>>>       
>>>> +	ret = kexec_crash_image != NULL;
>>>> +	mutex_unlock(&kexec_mutex);
>>>> +	return ret;
>>>> +}
>>>> +
>>>> +size_t get_crash_memory_size(void)
>>>> +{
>>>> +	size_t size;
>>>> +	if (!mutex_trylock(&kexec_mutex))
>>>> +		return 1;
>>>>     
>>>>         
>>> We don't need trylock on this code path 
>>>
>>>   
>>>       
>> Hmm, crashk_res is a global struct, so other process can also
>> change it... but currently no process does that, right?
>>
>>     
>
> We still need the lock.  Just doing trylock doesn't instead
> of just sleeping doesn't seem to make any sense on these
> code paths.
>
>   

Ok, got it.

>>>   
>>>       
>>>> +	start = crashk_res.start;
>>>> +	end = crashk_res.end;
>>>> +
>>>> +	if (new_size >= end - start + 1) {
>>>> +		ret = -EINVAL;
>>>> +		if (new_size == end - start + 1)
>>>> +			ret = 0;
>>>> +		goto unlock;
>>>> +	}
>>>> +
>>>> +	start = roundup(start, PAGE_SIZE);
>>>> +	end = roundup(start + new_size, PAGE_SIZE) - 1;
>>>> +	npages = (end + 1 - start ) / PAGE_SIZE;
>>>> +
>>>> +	pages = kmalloc(sizeof(struct page *) * npages, GFP_KERNEL);
>>>> +	if (!pages) {
>>>> +		ret = -ENOMEM;
>>>> +		goto unlock;
>>>> +	}
>>>> +	for (i = 0; i < npages; i++) {
>>>> +		addr = end + 1 + i * PAGE_SIZE;
>>>> +		pages[i] = virt_to_page(addr);
>>>> +	}
>>>> +
>>>> +	vaddr = vm_map_ram(pages, npages, 0, PAGE_KERNEL);
>>>>     
>>>>         
>>> This is the wrong kernel call to use.  I expect this needs to look
>>> like a memory hotplug event.  This does not put the pages into the
>>> free page pool.
>>>   
>>>       
>> Well, I also wanted to use an memory-hotplug API, but that will make the code
>> depend on memory-hotplug, which certainly is not what we want...
>>
>> I checked the mm code, actually what I need is an API which is similar to
>> add_active_range(), but add_active_range() can't be used here since it is marked
>> as "__init".
>>
>> Do we have that kind of API in mm? I can't find one.
>>     
>
> Perhaps we will need to remove __init from add_active_range.  I know the logic
> but I'm not up to speed on the mm pieces at the moment.
>   

Not that simple, marking it as "__init" means it uses some "__init" data 
which will be dropped after initialization.

Thanks.

--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[Eric W. Biederman]

Amerigo Wang <amwang@redhat.com> writes:

> Not that simple, marking it as "__init" means it uses some "__init" data which
> will be dropped after initialization.

If we start with the assumption that we will be reserving to much and
will free the memory once we know how much we really need I see a very
simple way to go about this. We ensure that the reservation of crash
kernel memory is done through a normal allocation so that we have
struct page entries for every page.  On 32bit x86 that is an extra 1MB
for a 128MB allocation.

Then when it comes time to release that memory we clear whatever magic
flags we have on the page (like PG_reserve) and call free_page.

Eric

--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[Amerigo Wang]

Eric W. Biederman wrote:
> Amerigo Wang <amwang@redhat.com> writes:
>
>   
>> Not that simple, marking it as "__init" means it uses some "__init" data which
>> will be dropped after initialization.
>>     
>
> If we start with the assumption that we will be reserving to much and
> will free the memory once we know how much we really need I see a very
> simple way to go about this. We ensure that the reservation of crash
> kernel memory is done through a normal allocation so that we have
> struct page entries for every page.  On 32bit x86 that is an extra 1MB
> for a 128MB allocation.
>
> Then when it comes time to release that memory we clear whatever magic
> flags we have on the page (like PG_reserve) and call free_page.
>   

Hmm, my MM knowledge is not good enough to judge if this works...
I need to check more MM source code.

Can any MM people help?

Thanks.

--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[KAMEZAWA Hiroyuki]

On Mon, 17 Aug 2009 17:50:21 +0800
Amerigo Wang <amwang@redhat.com> wrote:

> Eric W. Biederman wrote:
> > Amerigo Wang <amwang@redhat.com> writes:
> >
> >   
> >> Not that simple, marking it as "__init" means it uses some "__init" data which
> >> will be dropped after initialization.
> >>     
> >
> > If we start with the assumption that we will be reserving to much and
> > will free the memory once we know how much we really need I see a very
> > simple way to go about this. We ensure that the reservation of crash
> > kernel memory is done through a normal allocation so that we have
> > struct page entries for every page.  On 32bit x86 that is an extra 1MB
> > for a 128MB allocation.
> >
> > Then when it comes time to release that memory we clear whatever magic
> > flags we have on the page (like PG_reserve) and call free_page.
> >   
> 
> Hmm, my MM knowledge is not good enough to judge if this works...
> I need to check more MM source code.
> 
> Can any MM people help?
> 
Hm, memory-hotplug guy is here.

Can I have a question ?

  - How crash kernel's memory is preserved at boot ?
    It's hidden from the system before mem_init() ?

Thanks,
-Kame







--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[Amerigo Wang]

KAMEZAWA Hiroyuki wrote:
> On Mon, 17 Aug 2009 17:50:21 +0800
> Amerigo Wang <amwang@redhat.com> wrote:
>
>   
>> Eric W. Biederman wrote:
>>     
>>> Amerigo Wang <amwang@redhat.com> writes:
>>>
>>>   
>>>       
>>>> Not that simple, marking it as "__init" means it uses some "__init" data which
>>>> will be dropped after initialization.
>>>>     
>>>>         
>>> If we start with the assumption that we will be reserving to much and
>>> will free the memory once we know how much we really need I see a very
>>> simple way to go about this. We ensure that the reservation of crash
>>> kernel memory is done through a normal allocation so that we have
>>> struct page entries for every page.  On 32bit x86 that is an extra 1MB
>>> for a 128MB allocation.
>>>
>>> Then when it comes time to release that memory we clear whatever magic
>>> flags we have on the page (like PG_reserve) and call free_page.
>>>   
>>>       
>> Hmm, my MM knowledge is not good enough to judge if this works...
>> I need to check more MM source code.
>>
>> Can any MM people help?
>>
>>     
> Hm, memory-hotplug guy is here.
>   

Hi, thank you!
> Can I have a question ?
>
>   - How crash kernel's memory is preserved at boot ?
>   

Use bootmem, I think.

>     It's hidden from the system before mem_init() ?
>   

Not sure, but probably yes. It is reserved in setup_arch() which is 
before mm_init() which calls mem_init().

Do you have any advice to free that reserved memory after boot? :)

Thanks.



--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[KAMEZAWA Hiroyuki]

On Tue, 18 Aug 2009 14:31:23 +0800
Amerigo Wang <amwang@redhat.com> wrote:
> Hi, thank you!
> > Can I have a question ?
> >
> >   - How crash kernel's memory is preserved at boot ?
> >   
> 
> Use bootmem, I think.
> 
I see.

In x86,
 
  setup_arch()
	-> reserve_crashkernel()
		-> find_and_reserve_crashkernel()
			-> reserve_bootmem_generic()

Then, all "active range" is already registered and there are memmap.


> >     It's hidden from the system before mem_init() ?
> >   
> 
> Not sure, but probably yes. It is reserved in setup_arch() which is 
> before mm_init() which calls mem_init().
> 
> Do you have any advice to free that reserved memory after boot? :)
> 

Let's see arch/x86/mm/init.c::free_initmem()

Maybe it's all you want.

	- ClearPageReserved()
	- init_page_count()
	- free_page()
	- totalram_pages++

But it has no argumetns. Maybe you need your own function or modification.
online_pages() does very similar. But, hmm,.. writing something open coded one
for crashkernel is not very bad, I think.

Thanks,
-Kame







--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[Amerigo Wang]

KAMEZAWA Hiroyuki wrote:
> On Tue, 18 Aug 2009 14:31:23 +0800
> Amerigo Wang <amwang@redhat.com> wrote:
>   
>> Hi, thank you!
>>     
>>> Can I have a question ?
>>>
>>>   - How crash kernel's memory is preserved at boot ?
>>>   
>>>       
>> Use bootmem, I think.
>>
>>     
> I see.
>
> In x86,
>  
>   setup_arch()
> 	-> reserve_crashkernel()
> 		-> find_and_reserve_crashkernel()
> 			-> reserve_bootmem_generic()
>
> Then, all "active range" is already registered and there are memmap.
>
>
>   
>>>     It's hidden from the system before mem_init() ?
>>>   
>>>       
>> Not sure, but probably yes. It is reserved in setup_arch() which is 
>> before mm_init() which calls mem_init().
>>
>> Do you have any advice to free that reserved memory after boot? :)
>>
>>     
>
> Let's see arch/x86/mm/init.c::free_initmem()
>
> Maybe it's all you want.
>
> 	- ClearPageReserved()
> 	- init_page_count()
> 	- free_page()
> 	- totalram_pages++
>
> But it has no argumetns. Maybe you need your own function or modification.
> online_pages() does very similar. But, hmm,.. writing something open coded one
> for crashkernel is not very bad, I think.
>   

Nice help!

Yeah, I think we can make that be a generic wrapper function so that 
both free_initmem() and shrink_crash_memory() can use it.

Then I will update and resend the whole patchset.

Thank you!



--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[Amerigo Wang]

KAMEZAWA Hiroyuki wrote:
> On Tue, 18 Aug 2009 14:31:23 +0800
> Amerigo Wang <amwang@redhat.com> wrote:
>   
>>>     It's hidden from the system before mem_init() ?
>>>   
>>>       
>> Not sure, but probably yes. It is reserved in setup_arch() which is 
>> before mm_init() which calls mem_init().
>>
>> Do you have any advice to free that reserved memory after boot? :)
>>
>>     
>
> Let's see arch/x86/mm/init.c::free_initmem()
>
> Maybe it's all you want.
>
> 	- ClearPageReserved()
> 	- init_page_count()
> 	- free_page()
> 	- totalram_pages++
>   

Just FYI: calling ClearPageReserved() caused an oops: "Unable to handle 
paging request".

I am trying to figure out why...

--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[KAMEZAWA Hiroyuki]

On Tue, 18 Aug 2009 18:35:32 +0800
Amerigo Wang <amwang@redhat.com> wrote:

> KAMEZAWA Hiroyuki wrote:
> > On Tue, 18 Aug 2009 14:31:23 +0800
> > Amerigo Wang <amwang@redhat.com> wrote:
> >   
> >>>     It's hidden from the system before mem_init() ?
> >>>   
> >>>       
> >> Not sure, but probably yes. It is reserved in setup_arch() which is 
> >> before mm_init() which calls mem_init().
> >>
> >> Do you have any advice to free that reserved memory after boot? :)
> >>
> >>     
> >
> > Let's see arch/x86/mm/init.c::free_initmem()
> >
> > Maybe it's all you want.
> >
> > 	- ClearPageReserved()
> > 	- init_page_count()
> > 	- free_page()
> > 	- totalram_pages++
> >   
> 
> Just FYI: calling ClearPageReserved() caused an oops: "Unable to handle 
> paging request".
> 
> I am trying to figure out why...
> 
Hmm...then....memmap is not there.
pfn_valid() check will help you. What arch ? x86-64 ?

Thanks,
-Kame

--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[Amerigo Wang]

KAMEZAWA Hiroyuki wrote:
> On Tue, 18 Aug 2009 18:35:32 +0800
> Amerigo Wang <amwang@redhat.com> wrote:
>
>   
>> KAMEZAWA Hiroyuki wrote:
>>     
>>> On Tue, 18 Aug 2009 14:31:23 +0800
>>> Amerigo Wang <amwang@redhat.com> wrote:
>>>   
>>>       
>>>>>     It's hidden from the system before mem_init() ?
>>>>>   
>>>>>       
>>>>>           
>>>> Not sure, but probably yes. It is reserved in setup_arch() which is 
>>>> before mm_init() which calls mem_init().
>>>>
>>>> Do you have any advice to free that reserved memory after boot? :)
>>>>
>>>>     
>>>>         
>>> Let's see arch/x86/mm/init.c::free_initmem()
>>>
>>> Maybe it's all you want.
>>>
>>> 	- ClearPageReserved()
>>> 	- init_page_count()
>>> 	- free_page()
>>> 	- totalram_pages++
>>>   
>>>       
>> Just FYI: calling ClearPageReserved() caused an oops: "Unable to handle 
>> paging request".
>>
>> I am trying to figure out why...
>>
>>     
> Hmm...then....memmap is not there.
> pfn_valid() check will help you. What arch ? x86-64 ?
>   

Hmm, yes, x86_64, but this code is arch-independent, I mean it should 
work or not work on all arch, no?

So I am afraid we need to use other API to free it...

Thanks.


--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[KAMEZAWA Hiroyuki]

On Wed, 19 Aug 2009 10:41:13 +0800
Amerigo Wang <amwang@redhat.com> wrote:

> KAMEZAWA Hiroyuki wrote:
> > On Tue, 18 Aug 2009 18:35:32 +0800
> > Amerigo Wang <amwang@redhat.com> wrote:
> >
> >   
> >> KAMEZAWA Hiroyuki wrote:
> >>     
> >>> On Tue, 18 Aug 2009 14:31:23 +0800
> >>> Amerigo Wang <amwang@redhat.com> wrote:
> >>>   
> >>>       
> >>>>>     It's hidden from the system before mem_init() ?
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> Not sure, but probably yes. It is reserved in setup_arch() which is 
> >>>> before mm_init() which calls mem_init().
> >>>>
> >>>> Do you have any advice to free that reserved memory after boot? :)
> >>>>
> >>>>     
> >>>>         
> >>> Let's see arch/x86/mm/init.c::free_initmem()
> >>>
> >>> Maybe it's all you want.
> >>>
> >>> 	- ClearPageReserved()
> >>> 	- init_page_count()
> >>> 	- free_page()
> >>> 	- totalram_pages++
> >>>   
> >>>       
> >> Just FYI: calling ClearPageReserved() caused an oops: "Unable to handle 
> >> paging request".
> >>
> >> I am trying to figure out why...
> >>
> >>     
> > Hmm...then....memmap is not there.
> > pfn_valid() check will help you. What arch ? x86-64 ?
> >   
> 
> Hmm, yes, x86_64, but this code is arch-independent, I mean it should 
> work or not work on all arch, no?
> 
> So I am afraid we need to use other API to free it...
> 
The, problem is whether memmap is there or not. That's all.
plz see init sequence and check there are memmap.
If memory-for-crash is obtained via bootmem,
Don't you try to free memory hole ?


Thanks,
-Kame




--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[Amerigo Wang]

KAMEZAWA Hiroyuki wrote:
> On Wed, 19 Aug 2009 10:41:13 +0800
> Amerigo Wang <amwang@redhat.com> wrote:
>
>   
>> KAMEZAWA Hiroyuki wrote:
>>     
>>> On Tue, 18 Aug 2009 18:35:32 +0800
>>> Amerigo Wang <amwang@redhat.com> wrote:
>>>
>>>   
>>>       
>>>> KAMEZAWA Hiroyuki wrote:
>>>>     
>>>>         
>>>>> On Tue, 18 Aug 2009 14:31:23 +0800
>>>>> Amerigo Wang <amwang@redhat.com> wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>>>     It's hidden from the system before mem_init() ?
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> Not sure, but probably yes. It is reserved in setup_arch() which is 
>>>>>> before mm_init() which calls mem_init().
>>>>>>
>>>>>> Do you have any advice to free that reserved memory after boot? :)
>>>>>>
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> Let's see arch/x86/mm/init.c::free_initmem()
>>>>>
>>>>> Maybe it's all you want.
>>>>>
>>>>> 	- ClearPageReserved()
>>>>> 	- init_page_count()
>>>>> 	- free_page()
>>>>> 	- totalram_pages++
>>>>>   
>>>>>       
>>>>>           
>>>> Just FYI: calling ClearPageReserved() caused an oops: "Unable to handle 
>>>> paging request".
>>>>
>>>> I am trying to figure out why...
>>>>
>>>>     
>>>>         
>>> Hmm...then....memmap is not there.
>>> pfn_valid() check will help you. What arch ? x86-64 ?
>>>   
>>>       
>> Hmm, yes, x86_64, but this code is arch-independent, I mean it should 
>> work or not work on all arch, no?
>>
>> So I am afraid we need to use other API to free it...
>>
>>     
> The, problem is whether memmap is there or not. That's all.
> plz see init sequence and check there are memmap.
> If memory-for-crash is obtained via bootmem,
> Don't you try to free memory hole ?
>   

Yes, I am checking the code. Thanks!

--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[Amerigo Wang]

KAMEZAWA Hiroyuki wrote:
> On Wed, 19 Aug 2009 10:41:13 +0800
> Amerigo Wang <amwang@redhat.com> wrote:
>
>   
>> KAMEZAWA Hiroyuki wrote:
>>     
>>> On Tue, 18 Aug 2009 18:35:32 +0800
>>> Amerigo Wang <amwang@redhat.com> wrote:
>>>
>>>   
>>>       
>>>> KAMEZAWA Hiroyuki wrote:
>>>>     
>>>>         
>>>>> On Tue, 18 Aug 2009 14:31:23 +0800
>>>>> Amerigo Wang <amwang@redhat.com> wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>>>     It's hidden from the system before mem_init() ?
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> Not sure, but probably yes. It is reserved in setup_arch() which is 
>>>>>> before mm_init() which calls mem_init().
>>>>>>
>>>>>> Do you have any advice to free that reserved memory after boot? :)
>>>>>>
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> Let's see arch/x86/mm/init.c::free_initmem()
>>>>>
>>>>> Maybe it's all you want.
>>>>>
>>>>> 	- ClearPageReserved()
>>>>> 	- init_page_count()
>>>>> 	- free_page()
>>>>> 	- totalram_pages++
>>>>>   
>>>>>       
>>>>>           
>>>> Just FYI: calling ClearPageReserved() caused an oops: "Unable to handle 
>>>> paging request".
>>>>
>>>> I am trying to figure out why...
>>>>
>>>>     
>>>>         
>>> Hmm...then....memmap is not there.
>>> pfn_valid() check will help you. What arch ? x86-64 ?
>>>   
>>>       
>> Hmm, yes, x86_64, but this code is arch-independent, I mean it should 
>> work or not work on all arch, no?
>>
>> So I am afraid we need to use other API to free it...
>>
>>     
> The, problem is whether memmap is there or not. That's all.
> plz see init sequence and check there are memmap.
> If memory-for-crash is obtained via bootmem,
> Don't you try to free memory hole ?
>   

Hi,

It looks like that mem_map has 'struct page' for the reserved memory, I 
checked my "early_node_map[] active PFN ranges" output, the reserved 
memory area for crash kernel is right in one range. Am I missing 
something here?

I don't know why that oops comes out, maybe because of no PTE for thoese 
pages?

Thanks.


--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[KAMEZAWA Hiroyuki]

On Thu, 20 Aug 2009 17:15:56 +0800
Amerigo Wang <amwang@redhat.com> wrote:
    
> > The, problem is whether memmap is there or not. That's all.
> > plz see init sequence and check there are memmap.
> > If memory-for-crash is obtained via bootmem,
> > Don't you try to free memory hole ?
> >   
> 
> Hi,
> 
> It looks like that mem_map has 'struct page' for the reserved memory, I 
> checked my "early_node_map[] active PFN ranges" output, the reserved 
> memory area for crash kernel is right in one range. Am I missing 
> something here?
> 
> I don't know why that oops comes out, maybe because of no PTE for thoese 
> pages?
> 
Hmm ? Could you show me the code you use ?

Thanks,
-Kame


--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[Amerigo Wang]

On Fri, Aug 21, 2009 at 09:34:52AM +0900, KAMEZAWA Hiroyuki wrote:
>On Thu, 20 Aug 2009 17:15:56 +0800
>Amerigo Wang <amwang@redhat.com> wrote:
>    
>> > The, problem is whether memmap is there or not. That's all.
>> > plz see init sequence and check there are memmap.
>> > If memory-for-crash is obtained via bootmem,
>> > Don't you try to free memory hole ?
>> >   
>> 
>> Hi,
>> 
>> It looks like that mem_map has 'struct page' for the reserved memory, I 
>> checked my "early_node_map[] active PFN ranges" output, the reserved 
>> memory area for crash kernel is right in one range. Am I missing 
>> something here?
>> 
>> I don't know why that oops comes out, maybe because of no PTE for thoese 
>> pages?
>> 
>Hmm ? Could you show me the code you use ?

(Sorry that I reply to you with my gmail, my work email can't send out
this message, probably because one of the destinations is broken...
I am the same person, don't be confused. :-)

Sure. Below is it:

+    for (addr = end + 1; addr < crashk_res.end; addr += PAGE_SIZE) {
+        printk(KERN_DEBUG "PFN is valid? %d\n", pfn_valid(addr>>PAGE_SHIFT));
+        ClearPageReserved(virt_to_page(addr));
+        init_page_count(virt_to_page(addr));
+        free_page(addr);
+        totalram_pages++;
+    }


pfn_valid() returns 1, and oops happens at ClearPageReserved().
('addr' is right between crashk_res.start and crashk_res.end)

Thank you!

--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[KAMEZAWA Hiroyuki]

On Fri, 21 Aug 2009 09:59:27 +0800
Amerigo Wang <xiyou.wangcong@gmail.com> wrote:

> On Fri, Aug 21, 2009 at 09:34:52AM +0900, KAMEZAWA Hiroyuki wrote:
> >On Thu, 20 Aug 2009 17:15:56 +0800
> >Amerigo Wang <amwang@redhat.com> wrote:
> >    
> >> > The, problem is whether memmap is there or not. That's all.
> >> > plz see init sequence and check there are memmap.
> >> > If memory-for-crash is obtained via bootmem,
> >> > Don't you try to free memory hole ?
> >> >   
> >> 
> >> Hi,
> >> 
> >> It looks like that mem_map has 'struct page' for the reserved memory, I 
> >> checked my "early_node_map[] active PFN ranges" output, the reserved 
> >> memory area for crash kernel is right in one range. Am I missing 
> >> something here?
> >> 
> >> I don't know why that oops comes out, maybe because of no PTE for thoese 
> >> pages?
> >> 
> >Hmm ? Could you show me the code you use ?
> 
> (Sorry that I reply to you with my gmail, my work email can't send out
> this message, probably because one of the destinations is broken...
> I am the same person, don't be confused. :-)
> 
> Sure. Below is it:
> 
> +    for (addr = end + 1; addr < crashk_res.end; addr += PAGE_SIZE) {
> +        printk(KERN_DEBUG "PFN is valid? %d\n", pfn_valid(addr>>PAGE_SHIFT));
> +        ClearPageReserved(virt_to_page(addr));
> +        init_page_count(virt_to_page(addr));
> +        free_page(addr);
> +        totalram_pages++;
> +    }
> 
> 
> pfn_valid() returns 1, and oops happens at ClearPageReserved().
> ('addr' is right between crashk_res.start and crashk_res.end)

Confused, 
  if    pfn_valid(addr >> PAGE_SHIFT) == true 

you should do
	ClearPageReserved(pfn_to_page(addr >> PAGE_SHIFT));

because addr is physical address, not virtual.
I guess crashk_res.end is physical address....

Thanks,
-Kame


> 
> Thank you!
> 

--
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>

Re: [Patch 8/8] kexec: allow to shrink reserved memory

[Amerigo Wang]

On Fri, Aug 21, 2009 at 11:03:09AM +0900, KAMEZAWA Hiroyuki wrote:
>On Fri, 21 Aug 2009 09:59:27 +0800
>Amerigo Wang <xiyou.wangcong@gmail.com> wrote:
>
>> On Fri, Aug 21, 2009 at 09:34:52AM +0900, KAMEZAWA Hiroyuki wrote:
>> >On Thu, 20 Aug 2009 17:15:56 +0800
>> >Amerigo Wang <amwang@redhat.com> wrote:
>> >    
>> >> > The, problem is whether memmap is there or not. That's all.
>> >> > plz see init sequence and check there are memmap.
>> >> > If memory-for-crash is obtained via bootmem,
>> >> > Don't you try to free memory hole ?
>> >> >   
>> >> 
>> >> Hi,
>> >> 
>> >> It looks like that mem_map has 'struct page' for the reserved memory, I 
>> >> checked my "early_node_map[] active PFN ranges" output, the reserved 
>> >> memory area for crash kernel is right in one range. Am I missing 
>> >> something here?
>> >> 
>> >> I don't know why that oops comes out, maybe because of no PTE for thoese 
>> >> pages?
>> >> 
>> >Hmm ? Could you show me the code you use ?
>> 
>> (Sorry that I reply to you with my gmail, my work email can't send out
>> this message, probably because one of the destinations is broken...
>> I am the same person, don't be confused. :-)
>> 
>> Sure. Below is it:
>> 
>> +    for (addr = end + 1; addr < crashk_res.end; addr += PAGE_SIZE) {
>> +        printk(KERN_DEBUG "PFN is valid? %d\n", pfn_valid(addr>>PAGE_SHIFT));
>> +        ClearPageReserved(virt_to_page(addr));
>> +        init_page_count(virt_to_page(addr));
>> +        free_page(addr);
>> +        totalram_pages++;
>> +    }
>> 
>> 
>> pfn_valid() returns 1, and oops happens at ClearPageReserved().
>> ('addr' is right between crashk_res.start and crashk_res.end)
>
>Confused, 
>  if    pfn_valid(addr >> PAGE_SHIFT) == true 
>
>you should do
>	ClearPageReserved(pfn_to_page(addr >> PAGE_SHIFT));
>
>because addr is physical address, not virtual.
>I guess crashk_res.end is physical address....

Excellent! You are right!

In fact, when I read the kexec code at the first time, I thought
'crashk_res' should hold physical address too, but after reading
more code I dropped that idea, so I am wrong. :-/

I will resend the whole patchset soon. It works now!

Thanks for your nice help, Hiroyuki!

--
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>