The hope of this RFC is to gather some high-level feedback and ideas,
since I couldn't really find any in-depth discussions on the mailing
list regarding gemfs, only the odd whisper. But after talking with
Joonas and grepping around, the parts of shmem fs we would initially
need to have for a drop in replacement would roughly be something
like:

struct file * drm_gemfs_setup_file(const char *name,
                                                 loff_t size,
                                                 unsigned long flags)

struct page * drm_gemfs_read_page(struct drm_gem_object *obj,
                                                      pgoff_t index)

struct page * drm_gemfs_read_page_gfp(struct drm_gem_object *obj,
                                                           pgoff_t index,
                                                           gfp_t gfp)

void drm_gemfs_truncate(struct drm_gem_object *obj)

Am I missing any?

This is pretty much what we already have, minus truncate_range, since
we don't care about partial truncation. Also we now operate at the gem
object level and not the mapping, does this seem appropriate?

The approach would then be to have our own in-kernel mount point for
gemfs, with probably a fair amount of copy-paste from shmem fs, but in
what should be a very stripped down form to suit our needs.

Once we have gemfs in place, we should then have the much needed
flexibility to change it as we see fit, for example, being able to
control how migration is handled or where the backing pages are
allocated from, which could be useful for handling stolen memory etc.

Does this all sound reasonable, am I missing anything?

Thanks,
Matt
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to