Re: mm->mmap_sem

[James Simmons <jsimmons@edgeglobal.com>]

> No, same problem.  You can't put a process to sleep without
> inter-processor interrupts on smp if its not running currently.

So only putting the current process to sleep doesn't cost anything. 
Putting another process to sleep does cost. I see this as being alot less
costly then the unmap the framebuffer and put the process to sleep on page
fault just before you access the accel engine solution. I though putting
another process to sleep would be easy. Just remove it from the run queue
and place it in the wait_queue. Mark the process as UNINTERUPPITABLE. Once
finished with the accel engine just remove it from the wait_queue and
place on the run_queue again. What am I missing?

Here is another question since its very expensive putting another process 
to sleep. If the process owns both the accel engine and framebuffer then I
should be able to put the process to sleep while the accel engine is
running? Since the process is asleep it can't acces the framebuffer but
the accel engine is still running on the card.    

  Another question. Do the cards lock when you access any part of the
framebuffer and the accel engine or do the cards lock when you access
the a part of the framebuffer which at the same time is being modified by
the accel engine? If this is the case I was thinking about this possible
solution. You could have ioctl call to /dev/gfx where you would specify a
window in the framebuffer you want. That area of the framebuffer would be
removed from process address space owning the framebuffer and added to the
process address space that owns /dev/gfx. This way you could have a
application open /dev/gfx in X windows it would  actually grab a piece of
the framebuffer for its self. The X server could not access this memory
region. Of course the X server would have to handle the seg fault
gracefully. The application could then write to the framebuffer directly.
Also the application could send accel commands to this region. Now since
both regions are controled by the same process we can put to sleep that
process until the accel engine is done.         

> You can't
> allow the kernel to touch the frame buffer if the user is using the
> accelerator or vice-versa.  Have an ioctl to lock the kernel out from
> updating, and only unlock it from user space when there's no activity for
> a while.

  These are mmapped regions. So locking out the kernel will not help. You
have to prevent userland from accessing the memory region to prevent the
machine from locking. 


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/