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@xxxxxxxxxx> 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... Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>