On Tue, Apr 26, 2011 at 4:22 PM, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote: > 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? In my case, I tested at embedded target(e.g: 2.6.29 , 2.6.32) based on arm cortex-a series for user responsiveness when trying to access mass files. > > -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. Thank you for your reviews. yes. we can simply reduce ZAP_BLOCK_SIZE. I mean that we can control ZAP_BLOCK_SIZE after consider a suitable munmap() operation size both preemptive mode and non-preemptive mode. > > Then again, what's the point, simply remove the whole thing (like I did) > and your problem is solved too. If we can get real-fast or real-time with advanced preemptive mmu_gather sufficiently according to user needs sometimes, I also think that that's good certainly. > > > -- Regards, Geunsik Lim ( Samsung Electronics ) Blog : http://blog.naver.com/invain/ e-Mail: geunsik.lim@xxxxxxxxxxx     Â leemgs@xxxxxxxxx , leemgs1@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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
