Re: [2.4.17/18pre] VM and swap - it's really unusable

Robert Love
2002-01-08T22:00:36Z

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