lkml.org 
[lkml]   [2001]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Preemption patch, some more feedback
From
Date
On Mon, 2001-09-10 at 11:41, Francis Galiegue wrote:
> Machine is Athlon 650, AMD Viper chipset, 256 MB RAM. Kernel is
> 2.4.9-ac10 + preempt patch + irc_conntrack patch from iptables.
>
> The preempt patch largely improves multimedia latency (no surprise on
> that), I can watch a DivX smoothly (with mplayer, gfx being Matrox G400)
> and compile various stuff behind.
>
> However, a very simple command destroys this completely:
>
> cat /dev/zero >/dev/null
>
> DivX playback then becomes sluggish, no visible difference in this case
> between stock kernel and "preempt" kernel.

A long-term lock must be held for the duration of `cat /dev/zero >
/dev/null' -- i dont know if it is in the access to /dev/null or
/dev/zero or in the basic file operation itself.

as long as a lock is held, preemption can not occur.

what do we do? for the short term, and the benefit of everyone (UP, SMP,
and preemption users) we need to eliminate long-held locks with a better
solution.

in the long term, we can look at having the preemption patch use various
different types of locks (priority locks, spin then sleep locks, etc.)

--
Robert M. Love
rml at ufl.edu
rml at tech9.net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:03    [W:0.043 / U:1.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site