Messages in this thread | | | Subject | Re: [2.4.17/18pre] VM and swap - it's really unusable | From | Robert Love <> | Date | 08 Jan 2002 17:01:53 -0500 |
| |
On Tue, 2002-01-08 at 16:57, Daniel Phillips wrote:
> > 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/
| |