On Tue, 2011-04-26 at 10:20 +0900, Geunsik Lim wrote: > Yes. I also checked the patch that you stated at LKML mailing list previously. > In my thinking. I want to keep ZAP_BLOCK_SIZE related contents > that adjusted by Ingo, Robert, Andrew, and so on a long time ago > because I believe that we can overcome below problems sufficiently > in real world. > . LKML archive - http://lkml.org/lkml/2002/7/24/273 > . LKML archive - http://lkml.org/lkml/2004/9/14/101 Real ancient world, that was 2004, well before we grew preemptible mmu_gather. > In my experience, I did overcome below problems with this patch > based on ZAP_BLOCK_SIZE. > > 1) To solve temporal CPU contention > (e.g: case that cpu contention is 93% ~ 96% according to mmap/munmap > to access mass files ) > 2) To get real-time or real-fast selectively on specified linux system I still don't get it, what kernel are you targeting here and why? -RT doesn't care, and clearly PREEMPT=n doesn't care because its not about latency at all, the only half-way point is PREEMPT=y and for that you could simply reduce ZAP_BLOCK_SIZE. Then again, what's the point, simply remove the whole thing (like I did) and your problem is solved too. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
