On Mon, Jan 27, 2014 at 05:09:59PM -0800, Taras Glek wrote: > > > John Stultz wrote: > >On 01/27/2014 04:12 PM, Minchan Kim wrote: > >>On Mon, Jan 27, 2014 at 05:23:17PM -0500, KOSAKI Motohiro wrote: > >>>- Your number only claimed the effectiveness anon vrange, but not file vrange. > >>Yes. It's really problem as I said. > >> From the beginning, John Stultz wanted to promote vrange-file to replace > >>android's ashmem and when I heard usecase of vrange-file, it does make sense > >>to me so that's why I'd like to unify them in a same interface. > >> > >>But the problem is lack of interesting from others and lack of time to > >>test/evaluate it. I'm not an expert of userspace so actually I need a bit > >>help from them who require the feature but at a moment, > >>but I don't know who really want or/and help it. > >> > >>Even, Android folks didn't have any interest on vrange-file. > > > >Just as a correction here. I really don't think this is the case, as > >Android's use definitely relies on file based volatility. It might be > >more fair to say there hasn't been very much discussion from Android > >developers on the particulars of the file volatility semantics (out > >possibly not having any particular objections, or more-likely, being a > >bit too busy to follow the all various theoretical tangents we've > >discussed). > > > >But I'd not want anyone to get the impression that anonymous-only > >volatility would be sufficient for Android's needs. > Mozilla is starting to use android's ashmem for discardable memory > within a single process: > https://bugzilla.mozilla.org/show_bug.cgi?id=748598 . > > Volatile ranges do help with that specific(uncommon?) use of ashmem. Thanks for the info. I'd like to ask a question. Do you prefer fvrange(fd, offset, len) or fadvise(fd, offset, len, advise) inteface rather than current vrange syscall interface for vrange-file? Because I think it would remove unnecessary mmap/munmap syscall for vrange interface as well as out of address space in 32bit machine. > > For Mozilla sharing memory across processes via ashmem is not a > nearterm project. It's something that is likely to require > significant rework. Process-local discardable memory can be > retrofited in a more straight-forward fashion. > > Taras -- Kind regards, Minchan Kim -- 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>