How do you handle speculation issues this raises. Right now, we can ensure that speculation only occurs on a granule boundary. mspec converts granules to uncached. With this patch, we would have to allocate a chunk, determine the size of page table backing that chunk, if it does not span the entire, free it and ask for a larger chunk. Alternatively, we would need to allocate a series of granule size chunks until none were found, then double that size and repeat. Have you shown a benefit from this work yet? In my and IIRC Jack's experience, nearly every place in the kernel that I have seen operating on vmem_map and struct page * that is performance critical have adequate TLB pressure to cause TLB replacement for the vmem_map. With your patch, how much extra work is the kernel going to need to do when replacing an entry which will essentially end up being used once? Please show a benfit before introducing this patch so we can ensure we do not introduce silent data corruption problems in the mspec allocations. If you want vmem_map to have variable page sizes, how about specifying the min and max at something crazy like base page size for ia64. Then you could still make the code generic and get it into the mainline kernel and not affect ia64. Thanks, Robin - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|