Questions about the zoned page frame allocator and fix mapped addresses
Hello, I have few more questions from my reading of "Understanding the Linux Kernel", chapter "Memory Management". - The book says, about releasing page frames to the per CPU cache - "no page frame is ever released to the cold cache: the kernel always assumes the freed page frame is hot with respect to the hardware cache". What is the reason for this decision ? - It is possible for a page to be in ZONE_NORMAL and yet have it's PG_reserved flag cleared. Is this correct ? - The function "fix_to_virt" for fix-mapped linear addresses does the following: return (0xfffff000UL - (idx << PAGE_SHIFT)); Why are the upper 4096 bytes not used, and the addressing starts from the top of the virtual address space - 4096 ? - The book says "each fix-mapped linear address maps one page frame of the physical memory". Shouldn't it be "maps one *physical location* of memory" rather than one page frame ? - My understanding is that the kernel page table entries for addresses > 896 MB would be empty and those addresses would be mapped using separate data structures used for temporary and permanent kernel mappings and non-contiguous page frame allocation. Is this wrong ? Thanks, Sunny
On Mon, 30 Mar 2015 20:25:38 +0530, Sunny Shah said:
- The book says, about releasing page frames to the per CPU cache - "no page frame is ever released to the cold cache: the kernel always assumes the freed page frame is hot with respect to the hardware cache". What is the reason for this decision ?
What can go wrong if the page is cold but the kernel assumes it's hot? What can go wrong if the kernel assumes it's cold but it's actually hot? (Hint - in which cases will it do a cache flush? In which cases is a cache flush needed? What happens in each case if the kernel guesses wrong?)
On Mon, Mar 30, 2015 at 10:46 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Mon, 30 Mar 2015 20:25:38 +0530, Sunny Shah said:
- The book says, about releasing page frames to the per CPU cache - "no page frame is ever released to the cold cache: the kernel always assumes the freed page frame is hot with respect to the hardware cache". What is the reason for this decision ?
What can go wrong if the page is cold but the kernel assumes it's hot?
What can go wrong if the kernel assumes it's cold but it's actually hot?
(Hint - in which cases will it do a cache flush? In which cases is a cache flush needed? What happens in each case if the kernel guesses wrong?)
Here's my understanding: - If a page is cold but kernel assumes it to be hot, a 'hot' allocation of that page would need it to be loaded into the CPU cache which means a little overhead. - If a page is hot but kernel assumes it to be cold, a future 'hot' allocation would eventually cause the invalidation of the CPU cache location corresponding to that page. But, even if the page were assumed to be hot, this might have anyway happened due to another page occupying the same cache location. This has confused me even more! I'm not sure if this is correct, but if it is, wouldn't this mean treating hot pages as cold is better ? I apologise for anything that I might be looking over or not thinking in the right direction. Please feel free to rebuke. Also, any help on my other questions would be greatly appreciated: - It is possible for a page to be in ZONE_NORMAL and yet have it's PG_reserved flag cleared. Is this correct ? - The function "fix_to_virt" for fix-mapped linear addresses does the following: return (0xfffff000UL - (idx << PAGE_SHIFT)); Why are the upper 4096 bytes not used, and the addressing starts from the top of the virtual address space - 4096 ? - The book says "each fix-mapped linear address maps one page frame of the physical memory". Shouldn't it be "maps one*physical location* of memory" rather than one page frame ? - My understanding is that the kernel page table entries for addresses > 896 MB would be empty and those addresses would be mapped using separate data structures used for temporary and permanent kernel mappings and non-contiguous page frame allocation. Is this wrong ? Thanks, Sunny
participants (2)
-
Sunny Shah -
Valdis.Kletnieks＠vt.edu