> maybe. I'm not entirely convinced... (I like the cleanup potential a lot > code wise.. but if it costs performance, then... well I'd hate to see > linux get slower for hugetlbfs) > > > If not, then I definitely wouldn't > > mind creating a default_pagetable_ops and calling into that. > > ... but without it to be honest, your patch adds nothing real.. there's > ONE user of your code, and there's no real cleanup unless you get rid of > all the special casing.... since the special casing is the really ugly > part of hugetlbfs, not the actual code inside the special case..
Well... I disagree there too :-) I've been working recently for example on some spufs improvements that require similar tweaking of the user address space as hugetlbfs. The problem I have is that while there are hooks in the generic code pretty much everywhere I need.... they are all hugetlb specific, that is they call directly into the hugetlb code. For now, I found ways of doing my stuff without hooking all over the page table operations (well, I had no real choices) but I can imagine it making sense to allow something (hugetlb being one of them) to take over part of the user address space. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
