> Why? I think it would be much better to have user space check the
> watermarks
Userspace cannot overflow a hardware FIFO. Only the kernel code
can do that, and you may or may not want the userspace -> kernel FIFO
behavior to match that of the kernel -> hardware behavior. Userspace
should wait on a semaphore or something.
> and flush the buffer as it reaches each water mark.
Userspace should not be telling the kernel when to flush the
kernel's buffers, only its own. Even if the hardware watermarks must be
polled (no IRQs), those belong to the kernel.
> Or at
> its option, some other policy. (Timer signals, optimal icache points
> between major rendering units, that sort of thing).
Sure, through a generic explicit-flush mechanism.
> I recall experiments with functional language memory allocators. They
> allocated memory from a large region by simply incrementing the
> address. Something they had to test was when the allocation reached the
> end of the region, to trigger a garbage collection.
>
> Two approaches were tried. One using a pages fault at the end and
> trapping the SIGSEGV, the other explicitly comparing the address on each
> allocation. The explicit compare won.
>
> That was just one fault every <insert large block of memory>. You are
> proposing faults much more often.
Not really, and especially not when the load is high. When you
are doing something like moving windows in X and the accel load is really
low, you can afford to fault quite often (relatively speaking) without the
resultant system overhead being too bad. In some cases the 4K intel
pagesize minimum buffer size may turn out to be too large, and most
flushes will be explicit from userspace or automated via the VSYNC IRQ
handler to keep things running smoothly.
With Quake3, although you have a huge stream of primitives to pass
to the kernel, you are going to be producing so many of them per frame at
such a steady rate that you can drop the number of pagefaults quite
dramatically and still be able to get a frame's worth of data to the
kernel. The technique scales very well because of this factor, even on
SMP.
> One obvious complaint about using page faults is the overhead of
> updating mappings. Inter-CPU TLB flushes are particularly expensive.
See above. You don't end up having to do them often enough that
it becomes a problem. Overhead from the Linux fault handling code is an
issue, but rawio and friends in 2.3 may be able to obviate some of the
problem.
Also another note about using page faults to handle accel access. Everyone
is worried about Inter-CPU TLB flushes. Their was a discussion about this
as well as fork threads and exec effects on the accel engine. Remember
OpenGL is designed around a graphics pipeline and each part of the
pipeline could have different grpahics context state. As you go down the
pipeline you switch the context state. Whats does this have to do with the
kernel handling. Well each process, which will be in each part of the
pipeline, must have a private grapohics context to self and a private
mapping. This means if a process mmaps a accel resource only that process
can only have access to it at the time its scheduled to run. If the
process forks and wants to use the accel resource then it must mmap
it as well. This way it will also have its own private graphics
context and private mapping. If a child tries to use the parents accel
resource then it segfault. Also when you context switch the process this
way you only have to flush only the local TBL.
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/