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

Daniel Phillips (phillips@bonn-fries.net)
Wed, 9 Jan 2002 10:17:01 +0100


On January 8, 2002 11:21 pm, Andrew Morton wrote:
> Daniel Phillips wrote:
> > The preemptible kernel can reschedule, on average, sooner than the
> > scheduling-point kernel, which has to wait for a scheduling point to roll
> > around.
>
> Yes. It can also fix problematic areas which my testing
> didn't cover.

I bet, with a minor hack, it can help you *find* those problem areas too.
You compile the two patches together and automatically log any event along
with the execution address, where your explicit schedule points failed to
reschedule in time. Sort of like a profile but suited exactly to your
problem.

This just detects the problem areas in normal kernel execution, not
spinlocks, but that is probably where most of the maintainance will be anyway.

By the way, did you check for latency in directory operations?

> Incidentally, there's the SMP problem. Suppose we
> have the code:
>
> lock_kernel();
> for (lots) {
> do(something sucky);
> if (current->need_resched)
> schedule();
> }
> unlock_kernel();
>
> This works fine on UP, but not on SMP. The scenario:
>
> - CPU A runs this loop.
>
> - CPU B is spinning on the lock.
>
> - Interrupt occurs, kernel elects to run RT task on CPU B.
> CPU A doesn't have need_resched set, and just keeps
> on going. CPU B is stuck spinning on the lock.
>
> This is only an issue for the low-latency patch - all the
> other approaches still have sufficiently bad worse-case that
> this scenario isn't worth worrying about.
>
> I toyed with creating spin_lock_while_polling_resched(),
> but ended up changing the scheduler to set need_resched
> against _all_ CPUs if an RT task is being woken (yes, yuk).

Heh, subtle. Thanks for pointing that out and making my head hurt.

--
Daniel
-
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/