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

[Jesse Barnes <jbarnes@engr.sgi.com>]

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).

Thanks,
Jesse
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>