[lkml]   [2001]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Significant performace improvements on reiserfs systems
On Thu, 2001-09-20 at 21:20, Andrew Morton wrote:
> This may not be practical.
> Take, for example, zap_page_range(). It simply has a lot
> of work to do, and it does it inside a spinlock. By doing
> it in a tight loop, it's optimal.
> There is no way to speed this function up by two or three orders
> of magnitude. (Well, there is: don't take the lock at all if
> the mm isn't shared, but this is merely an example. There are
> other instances).

Agreed, but...

> It seems that for a preemptive kernel to be successful, we need
> to globally alter the kernel so that it never holds locks for
> more than 500 microseconds. Which is what the conditional_schedule()
> (aka cooperative multitasking :)) patches do.
> It seems that there are no magic bullets, and low latency will
> forever have a global impact on kernel design, unless a way is
> found to reschedule with locks held. I recall that a large
> part of the MontaVista patch involved turning spinlocks into
> semaphores, yes? That would seem to be the way to go.

This would be the situation that solved the problem with little
complaint, huh?

Robert M. Love
rml at
rml at

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:03    [W:0.054 / U:6.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site