Messages in this thread | | | Date | Thu, 25 Sep 2008 04:30:14 +0200 | From | Nick Piggin <> | Subject | Re: [patch] mm: pageable memory allocator (for DRM-GEM?) |
| |
On Wed, Sep 24, 2008 at 06:20:22PM -0700, Keith Packard wrote: > On Thu, 2008-09-25 at 02:30 +0200, Nick Piggin wrote: > > > I guess so. A big problem of ioctls is just that they had been easier to > > add so they got less thought and review ;) If your ioctls are stable, > > correct, cross platform etc. then I guess that's the best you can do. > > One does what one can. Of course, in this case, 'cross platform' is just > x86/x86_64 as we're talking Intel integrated graphics. When (if?) we > figure out how to create a common interface across multiple cards for > some of these operations, we'll probably discover mistakes. We have > tried to be careful, but we cannot test in any other environment.
OK, that's all that can be asked I guess. Low level object / memory management hopefully can be shared.
> > Well, no not a seperate filesystem to do the pageable backing store, but > > a filesystem to do your object management. If there was a need for pageable > > RAM backing store, then you would still go back to the pageable allocator. > > Now that you've written one, we could go back and think about building a > file system and using fds for our operations. It would be a whole lot > easier than starting from scratch.
If it helps open some other possibilities, then great.
> > You can map them to userspace if you just take a page at a time and insert > > them into the page tables at fault time (or mmap time if you prefer). > > Currently, this will mean that mmapped pages would not be swappable; is > > that a problem? > > Yes. We leave a lot of objects mapped to user space as mmap isn't > exactly cheap. We're trying to use pread/pwrite for as much bulk I/O as > we can, but at this point, we're still mapping most of the pages we > allocate into user space and leaving them. Things like textures and > render buffers will get mmapped if there are any software fallbacks. > Other objects, like vertex buffers, will almost always end up mapped. > > One of our explicit design goals was to make sure user space couldn't > ever pin arbitrary amounts of memory; I'd hate to go back on that as it > seems like an important property for any subsystem designed to support > regular user applications in a general purpose desktop environment. I > don't want to trust user space to do the right thing, I want to enforce > that from kernel space.
OK. I will have to add some facilities to allow mmaps that go back through to tmpfs and be swappable... Thanks for the data point.
| |