Linux RT vs 'niceness' priority and preemption

I wanted some clarification on the differences between real-time linux process priority (-99 - -1) and normal user-level 'niceness' (0 - 40) priority, and the effects on scheduling and pre-emption.

Niceness scheduling is done (nowadays) by CFS- uses the the 0-40 priority as part of a calculation to figure out the size of the process 'time slice'. This makes sure that 'less nice' processes get more CPU time than more nice ones, but everything is still guaranteed some amount of CPU time. Processes are swapped in and out on the 'keel tick'. First question: is there any actual preempting here, besides that done on the keel tick? Basically, can a process ever interrupt another process and steal its CPU time (not due to keel tick)? Or does a process 'activation' (in nice user space) always have to wait until the next keel tick to become 'active' (in the case of a high-precision timer, network event, etc)? In other words, is there any way for a process to activate 'off tick'? Are there special keel events that can do this to a user-space process? Wouldn't this prevent asynchronous high-precision timer events?

To compliment the above, this is my understanding of realtime (specifically FIFO) scheduling done by the mode keel (in this case specifically the 'lowlatency' keel with IRQ keel threads exposed and keel preemption).

Linux handles hard IRQs from the hardware. This is the start of pretty much every event the computer does and leads to it eventually chewing on some piece of code somewhere. These hard IRQs are handled immediately and as fast as possible. The driver/keel will mostly try to copy data from the device and queue up its 'bottom half' work in a softirq. Most of the work is done in softirqs because it can be deferred and allows the CPU to receive hardware interrupts again. In the lowlatency keel you see these as actual threads, and they're subjected to the same 'realtime' priority scheduling as realtime processes. Realtime FIFO priority exhausts all processes at higher priorities first. Higher priority threads interrupt low priority threads on wakeup, vs nice priority processes that can only wake up on tick (right? see above question). FIFO threads at the same priority queue up in FIFO order and run until exhaustion (or preempted on a tick with nonvoluntary keel preempt?).

So besides confirming the above, second question is:

How does ksoftirqd fit into this? At least with the lowlatency keel, softirqs have their own visible thread/process that can be scheduled etc. Why is ksoftirqd still around? I know this thread should normally handle softirqs that cant be scheduled, but whats it doing now that softirqs have their own threads? I understand that ksoftirqd mostly exists to prevent the keel from starving user-space time, but doesnt RT FIFO have that ability anyways? Are there just some keel handlers that arent exposed as threads, and thus subject to the 'old rules'? And why is it at normal priority at nice 0? Why isnt it at low RT FIFO priority? ... and is there any harm putting it there?