From: David Laight <David.Laight@ACULAB.COM>
To: David Laight <David.Laight@ACULAB.COM>,
"'maarten.lankhorst@linux.intel.com'"
<maarten.lankhorst@linux.intel.com>,
"'mripard@kernel.org'" <mripard@kernel.org>,
"'sean@poorly.run'" <sean@poorly.run>,
"'airlied@linux.ie'" <airlied@linux.ie>,
"'daniel@ffwll.ch'" <daniel@ffwll.ch>,
"'dri-devel@lists.freedesktop.org'"
<dri-devel@lists.freedesktop.org>,
"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: RE: drm_cflush_sg() loops for over 3ms - scheduler not running tasks.
Date: Mon, 13 Jan 2020 17:39:35 +0000 [thread overview]
Message-ID: <9451c48fd66b4df0a5ede5391c4e64ef@AcuMS.aculab.com> (raw)
From: David Laight
> Sent: 13 January 2020 14:35
>
> I've been looking at why some RT processes don't get scheduled promptly.
> In my test the RT process's affinity ties it to a single cpu (this may not be such
> a good idea as it seems).
>
> What I've found is that the Intel i915 graphics driver uses the 'events_unbound'
> kernel worker thread to periodically execute drm_cflush_sg().
> (see https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_cache.c)
...
> This loop takes about 1us per iteration split fairly evenly between whatever is in
> for_each_sg_page() and drm_cflush_page().
> With a 2560x1440 display the loop count is 3600 (4 bytes/pixel) and the whole
> function takes around 3.3ms.
Actually not setting the cpu affinity makes no difference.
The process is woken up on the cpu it last ran on and sits 'waiting' until
drm_cflush_sg() finishes - even though the other cpu become idle.
No sign of sched_migrate_task event 'stealing' the process.
Even worse, because 'ticket locks' are used no other user processes can
acquire the same (user) mutex or be woken from cv_wait() until the
process actually runs.
This is a 5.4.0-rc7 kernel.
I think I saw some recent scheduler patches, I can try them until I can't build
with gcc 4.7.3 :-)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
reply other threads:[~2020-01-13 17:39 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=9451c48fd66b4df0a5ede5391c4e64ef@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=sean@poorly.run \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®