On Wed, 23 Nov 2016, Daniel Vetter wrote: > On Tue, Nov 22, 2016 at 09:26:11PM -0800, Hugh Dickins wrote: > > On Tue, 22 Nov 2016, Matthew Auld wrote: > > > On 9 November 2016 at 18:36, Hugh Dickins <hughd@xxxxxxxxxx> wrote: > > > > On Wed, 9 Nov 2016, Daniel Vetter wrote: > > > >> > > > >> Hi all -mm folks! > > > >> > > > >> Any feedback on these two? It's kinda an intermediate step towards a > > > >> full-blown gemfs, and I think useful for that. Or do we need to go > > > >> directly to our own backing storage thing? Aside from ack/nack from -mm I > > > >> think this is ready for merging. > > > > > > > > I'm currently considering them at last: will report back later. > > > > > > > > Full-blown gemfs does not come in here, of course; but let me > > > > fire a warning shot since you mention it: if it's going to use swap, > > > > then we shall probably have to nak it in favour of continuing to use > > > > infrastructure from mm/shmem.c. I very much understand why you would > > > > love to avoid that dependence, but I doubt it can be safely bypassed. > > > > > > Could you please elaborate on what specifically you don't like about > > > gemfs implementing swap, just to make sure I'm following? > > > > If we're talking about swap as implemented in mm/swapfile.c, and > > managed for tmpfs mainly through shmem_getpage_gfp(): that's slippery > > stuff, private to mm, and I would not want such trickiness duplicated > > somewhere down in drivers/gpu/drm, where mm developers and drm developers > > will keep on forgetting to keep it working correctly. > > > > But you write of gemfs "implementing" swap (and I see Daniel wrote of > > "our own backing storage"): perhaps you intend a disk or slow-mem file > > of your own, dedicated to paging gemfs objects according to your own > > rules, poked from memory reclaim via a shrinker. I certainly don't > > have the same quick objection to that: it may be a good way forward, > > though I'm not at all sure (and would prefer a name distinct from > > swap, so we wouldn't get confused - maybe gemswap). > > "our backing storage" was from the pov of the gpu, which is just > memory (and then normal swap). I think that's exactly the part you don't > like ;-) Yes ;) but never mind, reassuring answer below... > > Anwyway, objections noted, we'll go and beef up the interfaces exposed by > shmem in the style of this patch series here. What I'll expect in the > future beyong the migrate callback so we can unpin pages is asking shmem > to move the pages around to a different numa node, and also asking for > hugepages (if available). Thanks a lot for your feedback meanwhile. Migration callback, NUMA improvements, hugepages: all are reasonable things to be asking of shmem. I expect we'll have some to and fro on how best to fit whatever interface you want with how those are already handled, but none of those requests is reason to replace shmem by an independently backed gemfs. Hugh -- 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>