lkml.org 
[lkml]   [2008]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] mm: pageable memory allocator (for DRM-GEM?)
    Nick Piggin wrote:
    > Hi,
    >
    > So I promised I would look at this again, because I (and others) have some
    > issues with exporting shmem_file_setup for DRM-GEM to go off and do things
    > with.
    >
    > The rationale for using shmem seems to be that pageable "objects" are needed,
    > and they can't be created by userspace because that would be ugly for some
    > reason, and/or they are required before userland is running.
    >
    > I particularly don't like the idea of exposing these vfs objects to random
    > drivers because they're likely to get things wrong or become out of synch
    > or unreviewed if things change. I suggested a simple pageable object allocator
    > that could live in mm and hide the exact details of how shmem / pagecache
    > works. So I've coded that up quickly.
    >
    > Upon actually looking at how "GEM" makes use of its shmem_file_setup filp, I
    > see something strange... it seems that userspace actually gets some kind of
    > descriptor, a descriptor to an object backed by this shmem file (let's call it
    > a "file descriptor"). Anyway, it turns out that userspace sometimes needs to
    > pread, pwrite, and mmap these objects, but unfortunately it has no direct way
    > to do that, due to not having open(2)ed the files directly. So what GEM does
    > is to add some ioctls which take the "file descriptor" things, and derives
    > the shmem file from them, and then calls into the vfs to perform the operation.
    >
    > If my cursory reading is correct, then my allocator won't work so well as a
    > drop in replacement because one isn't allowed to know about the filp behind
    > the pageable object. It would also indicate some serious crack smoking by
    > anyone who thinks open(2), pread(2), mmap(2), etc is ugly in comparison...
    >
    > So please, nobody who worked on that code is allowed to use ugly as an
    > argument. Technical arguments are fine, so let's try to cover them.
    >
    >
    Nick,
    From my point of view, this is exactly what's needed, although there
    might be some different opinions among the
    DRM developers. A question:

    Sometimes it's desirable to indicate that a page / object is "cleaned",
    which would mean data has moved and is backed by device memory. In that
    case one could either free the object or indicate to it that it can
    release it's pages. Is freeing / recreating such an object an expensive
    operation? Would it, in that case, be possible to add an object / page
    "cleaned" function?

    /Thomas











    \
     
     \ /
      Last update: 2008-09-23 12:41    [W:4.124 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site