* Hugh Dickins <[email protected]> wrote:
> > It seems to trigger when a process with a large amount of memory swapped
> > out exits.
> >
> > Can this be solved with a cond_resched?
>
> Not that easily, I think.
>
> Are you testing with CONFIG_PREEMPT=y, as I'd expect? I thought
> cond_resched() adds nothing to that case (and we keep on intending but
> forgetting to make it compile away to nothing in that case). Or am I
> confused?
it still has an effect: if PREEMPT_BKL is disabled it drops the BKL. But
if PREEMPT_BKL is enabled too then cond_resched() has no effect.
(cond_resched_locked() does though)
back to the problem reported by Lee:
> > Xorg-18254 0dn.2 3us < (2110048)
> > Xorg-18254 0dn.2 4us : preempt_schedule (free_swap_and_cache)
> > Xorg-18254 0dn.2 5us : free_swap_and_cache (unmap_vmas)
> > Xorg-18254 0dn.2 6us : swap_info_get (free_swap_and_cache)
> > Xorg-18254 0dn.3 6us : swap_entry_free (free_swap_and_cache)
> > Xorg-18254 0dn.3 7us : find_trylock_page (free_swap_and_cache)
hm, where does the latency come from? We do have a lockbreaker in
unmap_vmas():
if (need_resched() ||
(i_mmap_lock && need_lockbreak(i_mmap_lock))) {
if (i_mmap_lock) {
*tlbp = NULL;
goto out;
}
cond_resched();
}
why doesnt this break up the 28ms latency?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
