On Mon 27-07-15 08:18:14, Jörn Engel wrote: > On Mon, Jul 27, 2015 at 09:08:42AM +0200, Michal Hocko wrote: > > On Fri 24-07-15 09:56:27, Jörn Engel wrote: > > > On Fri, Jul 24, 2015 at 09:04:21AM +0200, Michal Hocko wrote: > > > > On Thu 23-07-15 14:54:33, Spencer Baugh wrote: > > > > > From: Joern Engel <joern@xxxxxxxxx> > > > > > > > > > > Mapping large memory spaces can be slow and prevent high-priority > > > > > realtime threads from preempting lower-priority threads for a long time. > > > > > > > > How can a lower priority task block the high priority one? Do you have > > > > preemption disabled? > > > > > > Yes. > > We have kernel preemption disabled. A lower-priority task in a system > call will block higher-priority tasks. This is an inherent problem of !PREEMPT, though. There are many loops which can take quite some time but we do not want to sprinkle cond_resched all over the kernel. On the other hand these io/remap resp. vunmap page table walks do not have any cond_resched points AFAICS so we can at least mimic zap_pmd_range which does cond_resched. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>