Hi !
> Wait a minute. For me a 'kernel lock' is not acquired by the application
> directly at its initiative. It is used _inside_ the kernel between various
> parts of the kernel.
Yeah, but see below.
> So, in fact, I wonder if it's possible to put a kernel lock on the fb-area
> (the resource is the card memory) that can be used to enforce mutual
> exclusion between the hw accel _driver_ and the memory mapping mechanism.
> Understand that I have little understanding of how memory mapping works
> especially in linux. More precisely, is there any kernel code executed
> when an user-process writes in a memory mapped area or is it directly
> handled by the MMU hardware?
It is handled by the MMU hardware. And that is the problem. Well - actually
it is the only way to have decent speed :-).
So what one must do to get the behaviour we need, i.e. kernel code being
executed at such an access, you can tell the MMU that the called page is not
present and must be swapped in. This will then trigger a CPU exception (much
like an interrupt) which can swap the page in.
However this is an expensive operation (both the marking as swapped out and
the swapping in), as the MMU state need to be flushed and cache areas need
to be invalidated.
> If everything is handled directly by the MMU, then I guess you are
> right and we have no mean of control.
Other than telling the MMU to unmap.
> Once we have accepted to
> memory map the fb into the userspace process adress space the only
> way to prevent it (even temporarily) to access this area is to
> unmap everything.
Well - to unmap the part that might conflict. This may vary between cards.
> However, it seems to me that, for such memory mapping, some code
> may be executed sometimes in the kernel, no ?
What do you mean by sometimes ?
Basically, if the MMU is set to provide a path to the fb, and simultaneous
access to FB and acceleration is dangerous, you have to explicitly program the
MMU to disable that area temporarily (which is expensive), or you have to
make sure no programs run that could potentially write to that area.
Disabling it temporarily seems like a good solution, as the program can run on
until it actually hits the fb. However this can make for a bigger performance
impact in some situations (where one process does much accel and another
much fb) that just disallowing the scheduling for fb-mapping processes
while the accel is running.
However for the general case I think the unmap method is best.
> Modern hardware is
> so intelligent today that it can move pages between virtual
> memory and a PCI device alone without any kernel intervention?
You are talking about AGP cards using virtual texture memory and such ?
That doesn't change the way the program looks at the memory, just the way the
video controller looks at its own plus the system memory.
Whatever hardware does - you have to trap the access to fb memory, what means
a performance penalty.
CU, Andy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
