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

[Daniel Phillips]

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