Messages in this thread | | | Subject | Re: [PATCH] 2.6.14 patch for supporting madvise(MADV_FREE) | From | Badari Pulavarty <> | Date | Wed, 02 Nov 2005 07:49:12 -0800 |
| |
On Wed, 2005-11-02 at 02:43 +0100, Andrea Arcangeli wrote: > On Tue, Nov 01, 2005 at 05:15:01PM -0800, Badari Pulavarty wrote: > > Here is the patch to support madvise(MADV_FREE) - which frees > > up the given range of pages and truncates the underlying backing > > store. This basically provides "punch hole into file" functionality. > > Currently it supports ONLY shmfs/tmpfs - where we have short term > > need. Other filesystems return -ENOSYS. > > MADV_FREE as a name isn't right if we return -ENOSYS for anonymoys > memory. > > MADV_FREE in other OS works _only_ on anonymous memory and returns > -EINVAL if used on filebacked vmas. Infact we probably should rename our > MADV_DONTNEED to MADV_FREE. > > http://docs.sun.com/app/docs/doc/816-5168/6mbb3hrde?a=view > > "This value cannot be used on mappings that have underlying file objects." > > Our MADV_DONTNEED exactly matches the MADV_FREE semantics, and it seems > the MADV_DONTNEED of other OS isn't destructive like ours. Except our > MADV_DONTNEED also works on filebacked mappings but it's destructive > only on anonymous memory. > > > I thought Andrew suggested MADV_REMOVE for the new feature.
Yep. My bad. Andrew did suggest MADV_REMOVE. Let me rename and generate patch once again !! Thanks for pointing out.
> > This feature didn't exist in other OS yet AFIK, so a new MADV_name for > it makes sense. I'm not completely against extending MADV_FREE but then we > shouldn't return -ENOSYS on anonymous memory and we should do the same > thing MADV_DONTNEED does on anonymous memory. Probably a new name is > safer to avoid confusion (think an application running MADV_FREE and > expecting -EINVAL when used on filebacked mappings). > > Thanks! >
Thanks, Badari
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |