Re: [PATCH 0/3] Volatile Ranges (v11)

[Minchan Kim <minchan@kernel.org>]

On Thu, Mar 20, 2014 at 09:13:59AM +0100, Jan Kara wrote:
> On Thu 20-03-14 10:09:54, Minchan Kim wrote:
> > Hello,
> > 
> > On Wed, Mar 19, 2014 at 11:12:02AM +0100, Jan Kara wrote:
> > > On Wed 19-03-14 09:49:18, Minchan Kim wrote:
> > > > On Tue, Mar 18, 2014 at 11:07:50AM -0700, John Stultz wrote:
> > > > > On Tue, Mar 18, 2014 at 8:11 AM, Minchan Kim <minchan@kernel.org> wrote:
> > > > > > 1) SIGBUS
> > > > > >
> > > > > > It's one of the arguable issue because some user want to get a
> > > > > > SIGBUS(ex, Firefox) while other want a just zero page(ex, Google
> > > > > > address sanitizer) without signal so it should be option.
> > > > > >
> > > > > >         int vrange(start, len, VRANGE_VOLATILE|VRANGE_ZERO, &purged);
> > > > > >         int vrange(start, len, VRANGE_VOLATILE|VRANGE_SIGNAL, &purged);
> > > > > 
> > > > > So, the zero-fill on volatile access feels like a *very* special case
> > > > > to me, since a null page could be valid data in many cases. Since
> > > > > support/interest for volatile ranges has been middling at best, I want
> > > > > to start culling the stranger use cases. I'm open in the future to
> > > > > adding a special flag or something if it really make sense, but at
> > > > > this point, lets just get the more general volatile range use cases
> > > > > supported.
> > > > 
> > > > I'm not sure it's special case. Because some user could reserve
> > > > a big volatile VMA and want to use the range by circle queue for
> > > > caching so overwriting could happen easily.
> > > > We should call vrange(NOVOLATILE) to prevent SIGBUS right before
> > > > overwriting. I feel it's unnecessary overhead and we could avoid
> > > > the cost with VRANGE_ZERO.
> > > > Do you think this usecase would be rare?
> > >   If I understand it correctly the buffer would be volatile all the time
> > > and userspace would like to opportunistically access it. Hum, but then with
> > > your automatic zero-filling it could see half of the page with data and
> > > half of the page zeroed out (the page got evicted in the middle of
> > > userspace reading it). I don't think that's a very comfortable interface to
> > > work with (you would have to very carefully verify the data you've read is
> > > really valid). And frankly in most cases I'm afraid the application would
> > > fail to do proper verification and crash randomly under memory pressure. So
> > > I wouldn't provide VRANGE_ZERO unless I come across real people for which
> > > avoiding marking the range as NONVOLATILE is a big deal and they are OK with
> > > handling all the odd situations that can happen.
> > 
> > Plaes think following usecase.
> > 
> > Let's assume big volatile cacne.
> > If there is request for cache, it should find a object in a cache
> > and if it found, it should call vrange(NOVOLATILE) right before
> > passing it to the user and investigate it was purged or not.
> > If it wasn't purged, cache manager could pass the object to the user.
> > But it's circular cache so if there is no request from user, cache manager
> > always overwrites objects so it could encounter SIGBUS easily
> > so as current sematic, cache manager always should call vrange(NOVOLATILE)
> > right before the overwriting. Otherwise, it should register SIGBUS handler
> > to unmark volatile by page unit. SIGH.
> > 
> > If we support VRANGE_ZERO, cache manager could overwrite object without
> > SIGBUS handling or vrange(NOVOLATILE) call. Just need is vrange(NOVOLATILE)
> > call while cache manager pass it to the user.
>   OK, that makes some sense but I don't think we have to implement this
> functionality in the beginning...

Yeb, I am not strong against the idea which starts syscall as simple one
but make room for future but I believe scenario I mentioned is one of
typical usecase for volatile cache and it could avoid vrange(NOVOLATILE)
which is heavier than vrange(VOLATILE) because NOVOLATILE should enumerate
all of ptes in the range at current implementation so reducing NOVOATILE
call looks important to me.


> 								Honza
> -- 
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR
> 
> --
> 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:"dont@kvack.org"> email@kvack.org </a>

-- 
Kind regards,
Minchan Kim

--
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:"dont@kvack.org"> email@kvack.org </a>