On Tue, Apr 09, 2013 at 03:36:20PM -0700, John Stultz wrote: > On 04/08/2013 10:07 PM, Minchan Kim wrote: > >On Mon, Apr 08, 2013 at 08:27:50PM -0700, John Stultz wrote: > >>marked volatile, it should remain volatile until someone who has the > >>file open marks it as non-volatile. The only time we clear the > >>volatility is when the file is closed by all users. > >Yes. We need it that clear volatile ranges when the file is closed > >by ball users. That's what we need and blow my concern out. > > Ok, sorry this wasn't more clear. In all the implementations I've > pushed, the volatility only persists as long as someone holds the > file open. Once its closed by all users, the volatility is cleared.
I now confirmed it with your implementation. Sorry for the confusing without looking into your code in detail. :( > > Hopefully that calms your worries here. :) Yeb. > > > > >>I think the concern about surprising an application that isn't > >>expecting volatility is odd, since if an application jumped in and > >>punched a hole in the data, that could surprise other applications > >>as well. If you're going to use a file that can be shared, > >>applications have to deal with potential changes to that file by > >>others. > >True. My concern is delayed punching without any client of fd and > >there is no interface to detect some range of file is volatile state or > >not. It means anyone mapped a file with shared could encunter SIGBUS > >although he try to best effort to check it with lsof before using. > > I'll grant the SIGBUG semantics create the potential for stranger > behavior then usual, but I think the use cases are still attractive > enough to try to make it work. Indeed. > > > >>To me, the value in using volatile ranges on the file data is > >>exactly because the file data can be shared. So it makes sense to me > >>to have the volatility state be like the data in the file. I guess > >>the only exception in my case is that if all the references to a > >>file are closed, we can clear the volatility (since we don't have a > >>sane way for the volatility to persist past that point). > >Agree if you provide to clear out volatility when file are closed by > >all stakeholder. > > Agreed. > > > >>One question that might help resolve this: Would having some sort of > >>volatility checking interface be helpful in easing your concern > >>about applications being surprised by volatility? > >If we can provide above things, I think we don't need such interface > >until someone want it with reasonable logic. > > Sure, I just wanted to know if you saw a need right away. For now we > can leave it be. > > >>True. And performance needs to be good if this hinting interface is > >>to be used easily. Although I worry about performance trumping sane > >>semantics. So let me try to implement the desired behavior and we > >>can measure the difference. > >NP. But keep in mind that mmap_sem was really terrible for performance > >when I took a expereiment(ie, concurrent page fault by many threads > >while a thread calls mmap). > >I guess primary reason is CONFIG_MUTEX_SPIN_ON_OWNER. > >So at least, we should avoid it by introducing new mode like > >VOLATILE_ANON|VOLATILE_FILE|VOLATILE_BOTH if we want to > >support mvrange-file and mvragne interface was thing userland people > >really want although ashmem have used fd-based model. > > The VOLATILE_ANON|VOLATILE_FILE|VOLATILE_BOTH may be an interesting > compromise. > > Though, if one marks a VOLATILE_ANON range on an address that's an > mmaped file, how do we detect this and provide a sane error value > without checking the vmas? > Should we check vma? If there are conflict with existing vrange type, just return an -EINVAL? > > thanks > -john > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"d...@kvack.org";> em...@kvack.org </a> -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
