> > this is the normal sys_exit()->exit_mmap()->unmap_vmas() path. It's> > weird that it generated a 2ms latency. What are the values of> > voluntary_preemption and kernel_preemption on your current kernel? With> > a 2:0 setting we ought to have a reschedule point every 32 pages. Do> > you know which application triggers this latency and is it easy to> > reproduce?> > > > 2 and 1. Now that I think about it, this could have happened during> bootup, before my rc.local set these. I will try passing them on the> kernel command line.

hm, if you enabled kernel_preemption then the get_user_pages() fix in-J3 should already be available via normal kernel preemption, becausemake_pages_present() is preemptible. I am wondering whether thepreempt-timing patch properly deals with CONFIG_PREEMPT? Did thoselatencies get accompanied by a real Alsa XRUN as well? (assuming you canset the XRUN threshold to be close to the preempt-timing threshold.)

> Not sure I understand the difference between 2:1 and 2:0. Would the> latter make the kernel only preemptible at the voluntary preemption> points?

yes, this is the default on bootup. 1:0 is in essence what we are usingin the latest development kernels of Fedora Core 3, hence the focus anddistinction. It is an intermediate preemptability step between thevanilla kernel and full CONFIG_PREEMPT. If the concept produces a stableenough kernel for use in bigger distros such as FC3 it could pave theway for more mainstream acceptance of CONFIG_PREEMPT.

> > does this one trigger when you are using the VGA console? (or fbcon)?> > > > it's not immediately obvious to me precisely where this latency comes> > from, it would be nice to know how to reproduce it.> > It think this one was caused by switching virtual consoles. At one> point Andrew Morton suggested I remove the (un)lock_kernel calls from> do_tty_write. This fixed the problem, with no detectable side> effects. Maybe this could be incorporated into voluntary-preempt, it> would be useful to have more than one person to test it.

if it's the text consoles that you used then most latencies are causedby the text-video-RAM copying. Even today's fast videocards do that withvery bad performance - especially since we often do copies withinvideoram too. Such a copying of ~6K of videoram can easily take 3-4msecs.

If the tty layer is run without the kernel lock then this copyingbecomes preemptible. Could you send me the current tty-unlock patch thatyou are using? (i've seen some early ones.)