On Fri, Feb 20, 2004 at 03:37:26PM -0500, Daniel Phillips wrote:

Hi Paul,

quoted

I cannot think of any reasonable alternative to passing the parameter
down either, as it certainly does not be reasonable to duplicate the
code...

Yes, it's simply the (small) price that has to be paid in order to be able to 
boast about our accurate semantics.

;-)

quoted

How about something like "private_too" instead of "zap"?

How about just "all", which is what we mean.

Fair enough, certainly keeps a few more lines of code within 80 columns.

quoted

quoted

-void zap_page_range(struct vm_area_struct *vma,
-			unsigned long address, unsigned long size)
+void invalidate_page_range(struct vm_area_struct *vma,

Would it be useful for this to be inline?  (Wouldn't seem so,
zapping mappings has enough overhead that an extra level of
function call should be deep down in the noise...)

Yes, it doesn't seem worth it just to save a stack frame.

Actually, I erred there in that invalidate_mmap_range should not export the 
flag, because it never makes sense to pass in non-zero from a DFS.

Doesn't vmtruncate() want to pass non-zero "all" in to
invalidate_mmap_range() in order to maintain compatibility with existing
Linux semantics?

quoted

Doesn't the new argument need to be passed down through
invalidate_mmap_range_list()?

It does, thanks for the catch.  Please bear with me for a moment while I 
reroll this, then hopefully we can move on to the more interesting discussion 
of whether it's worth it.  (Yes it is :)

;-)

						Thanx, Paul
--
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/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>