On 09/21/2016 05:05 AM, Michal Hocko wrote: > On Tue 20-09-16 10:43:13, Dave Hansen wrote: >> On 09/20/2016 08:52 AM, Rui Teng wrote: >>> On 9/20/16 10:53 PM, Dave Hansen wrote: >> ... >>>> That's good, but aren't we still left with a situation where we've >>>> offlined and dissolved the _middle_ of a gigantic huge page while the >>>> head page is still in place and online? >>>> >>>> That seems bad. >>>> >>> What about refusing to change the status for such memory block, if it >>> contains a huge page which larger than itself? (function >>> memory_block_action()) >> >> How will this be visible to users, though? That sounds like you simply >> won't be able to offline memory with gigantic huge pages. > > I might be missing something but Is this any different from a regular > failure when the memory cannot be freed? I mean > /sys/devices/system/memory/memory API doesn't give you any hint whether > the memory in the particular block is used and > unmigrateable. It's OK to have free hugetlbfs pages in an area that's being offline'd. If we did that, it would not be OK to have a free gigantic hugetlbfs page that's larger than the area being offlined. It would be a wee bit goofy to have the requirement that userspace go find all the gigantic pages and make them non-gigantic before trying to offline something. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>