At some point in the past, I wrote:

quoted

Okay, first off why are you using a list linked through page->private?
page->list is fully available for such tasks.

On Thu, Nov 21, 2002 at 05:54:22PM -0800, Seth, Rohit wrote:

Don't really need a list_head kind of thing for always inorder complete
traversal. list_head (slightly) adds fat in data structures as well as
insertaion/removal. Please le me know if anything that prohibits the use of
page_private field for internal use.

page->private is also available for internal use. The objection here
was about not using the standardized list macros. I'm not convinced
about the fat since the keyspace is tightly bounded and the back
pointers are in struct page regardless. (And we also just happen to
know page->lru is also available though I'd not suggest using it.)


At some point in the past, I wrote:

quoted

Third, the hugetlb_release_key() in unmap_hugepage_range() is 
the one that should be removed [along with its corresponding 
mark_key_busy()], not the one in sys_free_hugepages(). 
unmap_hugepage_range() is doing neither setup nor teardown of 
the key itself, only the pages and PTE's. I would say 
key-level refcounting belongs to sys_free_hugepages().

On Thu, Nov 21, 2002 at 05:54:22PM -0800, Seth, Rohit wrote:

It is not mandatory that user app calls free_pages.  Or even in case of app
aborts this call will not be made.  The internal structures are always
released during the exit (with last ref count) along with free of underlying
physical pages.  

Hmm, I can understand caution wrt. touching core. I suspect vma->close()
should do hugetlb_key_release() instead of sys_free_hugepages()?

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