Re: [PATCH]: Option to run cache reap in thread mode

Dimitri Sivanich
2004-06-16T16:51:55Z

On Wed, Jun 16, 2004 at 12:25:11PM -0400, Jesse Barnes wrote:
> On Wednesday, June 16, 2004 12:07 pm, Christoph Hellwig wrote:
> > Well, if you want deterministic interrupt latencies you should go for a
> > realtime OS.
>
> Although I don't want to see another kernel thread added as much as the next
> guy, I think that minimizing the amount of time that irqs are turned off is
> probably a good thing in general. For example, the patch to allow interrupts
> in spin_lock_irq if the lock is already taken is generally a really good
> thing, because even though reducing lock contention should be a goal, locks
> by their very nature are taken sometimes, and allowing other CPUs to get
> useful work done while they're waiting for it is obviously desirable.
>
> > I know Linux is the big thing in the industry, but you're
> > really better off looking for a small Hard RT OS.
>
> Sure, for some applications, an RTOS is necessary. But it seems like keeping
> latencies down in Linux is a good thing to do nonetheless.
>
> Can you think of other ways to reduce the length of time that interrupts are
> disabled during cache reaping? It seems like the cache_reap loop might be a
> candidate for reorganization (though that would probably imply other
> changes).

I have another patch forthcoming that does some reorganizing of the locking.
With the two patches I see substantial improvement.

>
> Thanks,
> Jesse