Priority is currently, and sensibly, by process. A process may run user
code, do sys-calls, or field interrupts both soft and hard. Now do you want to
adjust the priority at every transition?
> Lowering the latency, sure the low latency code probably does nearly as well
> as the preempt patch. that's fine. Shortening the time locks are held by
> better code can help to a certain extent (unless a lot of the kernel code is
> poorly written, which i doubt). at it's present state though, my idea to
> fix the kernel would be to give parts of the kernel where locks are made,
"Fix" what? What is the objective of your fix?
> that shouldn't be broken normally, higher priorities. That way we can
> distinguish between safe locks to preempt at and the ones that can do harm.
> But those people who require their app to be treated special can run it
> with -20 and preempt everything. To me that makes sense. Is there a
So:
get semaphore on slab memory and raise priority
get preempted by "treated special" app that then
does an operation on the slab queues
Is that what you want?
> reason why it doesn't? Besides ethstetics. the only way the ethsetic
It doesn't work? Is that a sufficient reason?
-- --------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/