[EMAIL PROTECTED] wrote:
> It is handled by the MMU hardware. And that is the problem. Well - actually
> it is the only way to have decent speed :-).
OK. So, you need to unmap (to trigger page faults at least). I agree with
you.
I thought finer kernel control was possible.
> > 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 ?
I thought to the SMP case - because memory sharing between processes
may already have given rise to mechanisms we could reuse. But I suppose
also, as you say, that such mechanisms will also need to re-program the
MMU and incur the same perf. penalty as unmapping the fb.
What happens in the SMP case then? If two processes share a memory area?
Are shared memory mechanisms totally different from those of memory mapping?
I ask this question because, with multiple CPUs and thus multiple L1 caches,
the MMU should then _also_ handle cache coherence issues... But I guess it
is the case.
> However for the general case I think the unmap method is best.
I do to. There are TWO hardware devices that can access the fb
memory: the MMU and the graphic accelerator. If letting both
enabled can lock up the machine, you need to stop one before
using the other...
BTW, is it the unmap-ping process that is expensive, or is it the
subsequent (potential) page fault handling?
There is a similar issue that _may_ arise between the 2d and 3d
accelerated engines. But for them, in a KGI controlled design,
we can do the arbitration inside the KGI driver. (BTW, this is
again a statement that supports the idea of kernel-controlled
access to the card processing units - as opposed to memory
mapping the whole accel registers set to a userspace program. ;-)
Rodolphe
