All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Vlasenko <vda.linux@googlemail.com>
To: Lee Revell <rlrevell@joe-job.com>
Cc: Jan Engelhardt <jengelh@linux01.gwdg.de>,
	Eric Piel <Eric.Piel@tremplin-utc.net>,
	mplayer-users@mplayerhq.hu, linux-kernel@vger.kernel.org
Subject: Re: mplayer + heavy io: why ionice doesn't help?
Date: Tue, 22 Aug 2006 18:26:08 +0200	[thread overview]
Message-ID: <200608221826.08802.vda.linux@googlemail.com> (raw)
In-Reply-To: <1156109768.10565.55.camel@mindpipe>

> > I eliminated skips due to CPU and disk using
> > nice and -cache 8000. I still can make it skip
> > when my KDE background picture is changing.
> > 
> 
> I also must run mplayer at nice -20 for it to be usable.
> 
> > I think that these skips are caused by the X server.
> > It has no prioritization for request handling and
> > thus it does not paint mplayer output fast enough:
> > it needs to repaint background and semi-transparent
> > konsole(s), and that is taking a few seconds at least.
> > 
> > This is probably aggravated by serializing nature of Xlib,
> > according to:
> > 
> > http://en.wikipedia.org/wiki/XLib
> > http://en.wikipedia.org/wiki/XCB
> 
> I think the problem is also due to mplayer's faulty design.  It should
> be multithreaded and use RT threads for the time sensitive work, like
> all professional AV applications and many other consumer players do.

RT - yes, multithreaded - unsure. Witness how squid manages to
serve hundreds of simultaneous streams using just a single process.

Multithreading seems cool on the first glance and it is easier to code
than clever O_NONBLOCK/select/poll/etc stuff. However,
on single-CPU boxes, which are still a majority, multithreading
just incurs context switching penalty. It cannot magically
make CPU do more work in a unit of time.
--
vda

  parent reply	other threads:[~2006-08-22 16:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-18 17:37 mplayer + heavy io: why ionice doesn't help? Denis Vlasenko
2006-08-18 17:57 ` Nick Warne
2006-08-18 18:01 ` Eric Piel
2006-08-19 18:04   ` Denis Vlasenko
2006-08-20  8:22     ` Jan Engelhardt
2006-08-20 14:43       ` Lee Revell
2006-08-20 16:43         ` Denis Vlasenko
2006-08-20 21:36           ` Lee Revell
2006-08-20 22:04             ` Jan Engelhardt
2006-08-22 16:26             ` Denis Vlasenko [this message]
2006-08-22 17:37               ` Jan Engelhardt
2006-08-22 17:38               ` Xavier Bestel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200608221826.08802.vda.linux@googlemail.com \
    --to=vda.linux@googlemail.com \
    --cc=Eric.Piel@tremplin-utc.net \
    --cc=jengelh@linux01.gwdg.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mplayer-users@mplayerhq.hu \
    --cc=rlrevell@joe-job.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.