lkml.org 
[lkml]   [2013]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 0/4] Support vranges on files
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.

Hopefully that calms your worries here. :)



>> 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.


>> 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?


thanks
-john



\
 
 \ /
  Last update: 2013-04-10 01:01    [W:0.056 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site