> What somehow got lost in this discussion, that both patches don't
> necessarily conflict with each other, they both attack the same problem
> with different approaches, which complement each other. I prefer to get
> the best of both patches.
> The ll patch identifies problem, which preempt alone can't fix, on the
> other hand the ll patch inserts schedule calls all over the place, where
> preempt can handle this transparently. So far I haven't seen any
> evidence, that preempt introduces any _new_ serious problems, so I'd
> rather like to see to get the best out of both.
Good point. In fact, I have an "ll patch" for preempt-kernel, it is
called lock-break and available at
ftp://ftp.kernel.org/pub/linux/kernel/people/rml/lock-break
While I am not so sure this sort of explicit work is the answer -- I'd
much prefer to work on the algorithms to shorten lock time or lock into
different locks -- it does work. The work is based heavily on Andrew's
ll patch but designed for use with preempt-kernel. This means we can
drop some of the conditional schedules that aren't needed, and in others
we don't need to call schedule (just drop the locks).
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/