> > True (re spinlock weight in preemptible kernel) but how is that not
> > comparable to explicit scheduling points? Worse, the preempt-kernel
> > typically does its preemption on a branch on return to interrupt
> > (similar to user space's preemption). What better time to check and
> > reschedule if needed?
>
> The per-spinlock cost I was refering to is the cost of the inc/dec per
> spinlock. I guess this cost is small enough as to be hard to measure, but
> I have not tried so I don't know. Curiously, none of the people I've heard
> making pronouncements on the overhead of your preempt patch seem to have
> measured it either.
;-)
If they did I suspect it would be minimal. Andrew's point on complexity
and overhead in this manner is exact -- such thinks are just not an
issue.
I see two valid arguments against kernel preemption, and I'll be the
first to admit them:
- we introduce new problems with kernel programming. specifically, the
issue with implicitly locked per-CPU data. honestly, this isn't a huge
deal. I've been working on preempt-kernel for awhile now and the
problems we have found and fixed are minimal. admittedly, however,
especially wrt the future, preempt-kernel may introduce new concerns. I
say let's rise to meet them.
- we don't do enough for the worst-case latency. this is where future
work is useful and where preempt-kernel provides the framework for a
better kernel.
I want a better kernel. Hell, I want the best kernel. In my opinion,
one factor of that is having a preemptible kernel.
Robert Love
-
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/