Re: [Patch V2 2/2] sparc64 changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
Date: Fri, 25 Mar 2016 14:13:05 -0500

> On 03/25/2016 02:03 PM, David Miller wrote:
>> From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
>> Date: Fri, 25 Mar 2016 13:22:30 -0500
>> 
>>> On 03/24/2016 02:22 PM, David Miller wrote:
>>>> From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
>>>> Date: Wed, 23 Mar 2016 17:41:08 -0500
>>>>
>>>>> +	/* Check for a huge/THP page */
>>>>> +	paddr = pmd_is_huge(pte, vaddr, verbose);
>>>>> +	if (paddr)
>>>>> +		goto out;
>>>>  ...
>>>>> +	paddr = pte_to_pa(pte);
>>>>> +	paddr = paddr | (vaddr & ~PAGE_MASK);
>>>>
>>>> This handles transparent huge pages installed at the PMD level, but I don't
>>>> see that it handles huge PTEs properly, which are encoded at the PTE level.
>>>
>>> I've been looking at the huge page code again and I'm not sure what I'm
>>> missing. Isn't there still a huge PTE in the page table for every 8K
>>> page with the proper physical address bits?
>> 
>> Yes there is a huge PTE encoded every 8K, but I'm wondering about the
>> address masking et al. you are doing here...
> 
> I'm pretty sure it works. In set_huge_pte_at():
> 
>         for (i = 0; i < (1 << HUGETLB_PAGE_ORDER); i++) {
>                 set_pte_at(mm, addr, ptep, entry);
>                 ptep++;
>                 addr += PAGE_SIZE;
>                 pte_val(entry) += PAGE_SIZE;
>         }
> 
> Each pte correctly addresses an 8K page. The crash code doesn't really
> need to know it's part of a huge page.

Excellent, that looks good to me too.

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility



[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux