From: Andi Kleen <andi@firstfloor.org>
To: r6144 <rainy6144@gmail.com>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
sds@tycho.nsa.gov, linux-mm@kvack.org, jmorris@namei.org
Subject: Re: Sluggishness on a GEM system due to SELinux's sidtab_search_context() as well as get_unmapped_area()
Date: Wed, 17 Nov 2010 12:43:41 +0100 [thread overview]
Message-ID: <87tyjgqioi.fsf@basil.nowhere.org> (raw)
In-Reply-To: <1289793125.12243.18.camel@localhost.localdomain> (rainy6144@gmail.com's message of "Mon, 15 Nov 2010 11:52:05 +0800")
r6144 <rainy6144@gmail.com> writes:
> Hello,
>
> I'm noticing significant sluggishness when switching into a workspace
> where Evolution is running.
Interesting result. Adding some relevant ccs with full-quote.
I guess graphics really should do less mmaps, but the underlying
performance problems should be investigated too.
-Andi
>
> My kernel is Fedora 12's 2.6.32.16-150.fc12.x86_64 (I know it is
> old...), and the open source radeon (r600) driver is used. Oprofile
> shows the follows:
>
> CPU: Core 2, speed 2003 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a
> unit mask of 0x00 (Unhalted core cycles) count 100000
> Counted INST_RETIRED_ANY_P events (number of instructions retired) with
> a unit mask of 0x00 (No unit mask) count 100000
> samples % samples % image name app name
> symbol name
> 126807 31.2201 38744 28.3866 vmlinux Xorg
> (deleted) find_vma
> 48661 11.9804 3474 2.5453 vmlinux Xorg
> (deleted) mls_compute_sid
> 41806 10.2927 5700 4.1762 vmlinux Xorg
> (deleted) sidtab_search_context
> 11888 2.9268 4234 3.1021 Xorg (deleted) Xorg
> (deleted) /usr/bin/Xorg (deleted)
> 8660 2.1321 1589 1.1642 drm Xorg
> (deleted) /drm
> 6228 1.5333 6773 4.9624 radeon Xorg
> (deleted) /radeon
> 6214 1.5299 1832 1.3423 libc-2.11.2.so (deleted) Xorg
> (deleted) /lib64/libc-2.11.2.so (deleted)
> 5542 1.3644 4929 3.6113
> libpixman-1.so.0.16.6.#prelink#.3I5wow (deleted) Xorg
> (deleted) /usr/lib64/libpixman-1.so.0.16.6.#prelink#.3I5wow
> (deleted)
> 4149 1.0215 1776 1.3012 libexa.so Xorg
> (deleted) /usr/lib64/xorg/modules/libexa.so
> 4140 1.0193 640 0.4689 vmlinux oprofiled
> mls_compute_sid
> 3183 0.7837 847 0.6206 vmlinux Xorg
> (deleted) arch_get_unmapped_area_topdown
> ...
>
> Although I haven't looked into it, presumably Evolution is asking the X
> server to create and map a lot of TTM objects (pixmaps?). The creation
> of each object uses shmem_file_setup() and thus necessitates SELinux
> calls, and since the X process already has a lot of mappings (one
> mapping for each XRender glyph it seems, with "wc -l /proc/`pgrep
> Xorg`/maps" returning 6766), the mapping part could also be slow.
>
> I think the slowness of find_vma is related to
> https://bugzilla.kernel.org/show_bug.cgi?id=17531 . mls_compute_sid()
> did a linear search over the range transition rules and was therefore
> slow, but more recent kernels use a hash table so this problem has been
> solved. Another offender is sidtab_search_context() used to convert a
> SELinux context back into an sid, which is also a linear search as there
> is only a sid => context hash table, and I haven't seen any recent
> changes in this area.
>
> Please CC me as I'm not subscribed.
>
> r6144
>
--
ak@linux.intel.com -- Speaking for myself only.
WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <andi@firstfloor.org>
To: r6144 <rainy6144@gmail.com>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
sds@tycho.nsa.gov, linux-mm@kvack.org, jmorris@namei.org
Subject: Re: Sluggishness on a GEM system due to SELinux's sidtab_search_context() as well as get_unmapped_area()
Date: Wed, 17 Nov 2010 12:43:41 +0100 [thread overview]
Message-ID: <87tyjgqioi.fsf@basil.nowhere.org> (raw)
In-Reply-To: <1289793125.12243.18.camel@localhost.localdomain> (rainy6144@gmail.com's message of "Mon, 15 Nov 2010 11:52:05 +0800")
r6144 <rainy6144@gmail.com> writes:
> Hello,
>
> I'm noticing significant sluggishness when switching into a workspace
> where Evolution is running.
Interesting result. Adding some relevant ccs with full-quote.
I guess graphics really should do less mmaps, but the underlying
performance problems should be investigated too.
-Andi
>
> My kernel is Fedora 12's 2.6.32.16-150.fc12.x86_64 (I know it is
> old...), and the open source radeon (r600) driver is used. Oprofile
> shows the follows:
>
> CPU: Core 2, speed 2003 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a
> unit mask of 0x00 (Unhalted core cycles) count 100000
> Counted INST_RETIRED_ANY_P events (number of instructions retired) with
> a unit mask of 0x00 (No unit mask) count 100000
> samples % samples % image name app name
> symbol name
> 126807 31.2201 38744 28.3866 vmlinux Xorg
> (deleted) find_vma
> 48661 11.9804 3474 2.5453 vmlinux Xorg
> (deleted) mls_compute_sid
> 41806 10.2927 5700 4.1762 vmlinux Xorg
> (deleted) sidtab_search_context
> 11888 2.9268 4234 3.1021 Xorg (deleted) Xorg
> (deleted) /usr/bin/Xorg (deleted)
> 8660 2.1321 1589 1.1642 drm Xorg
> (deleted) /drm
> 6228 1.5333 6773 4.9624 radeon Xorg
> (deleted) /radeon
> 6214 1.5299 1832 1.3423 libc-2.11.2.so (deleted) Xorg
> (deleted) /lib64/libc-2.11.2.so (deleted)
> 5542 1.3644 4929 3.6113
> libpixman-1.so.0.16.6.#prelink#.3I5wow (deleted) Xorg
> (deleted) /usr/lib64/libpixman-1.so.0.16.6.#prelink#.3I5wow
> (deleted)
> 4149 1.0215 1776 1.3012 libexa.so Xorg
> (deleted) /usr/lib64/xorg/modules/libexa.so
> 4140 1.0193 640 0.4689 vmlinux oprofiled
> mls_compute_sid
> 3183 0.7837 847 0.6206 vmlinux Xorg
> (deleted) arch_get_unmapped_area_topdown
> ...
>
> Although I haven't looked into it, presumably Evolution is asking the X
> server to create and map a lot of TTM objects (pixmaps?). The creation
> of each object uses shmem_file_setup() and thus necessitates SELinux
> calls, and since the X process already has a lot of mappings (one
> mapping for each XRender glyph it seems, with "wc -l /proc/`pgrep
> Xorg`/maps" returning 6766), the mapping part could also be slow.
>
> I think the slowness of find_vma is related to
> https://bugzilla.kernel.org/show_bug.cgi?id=17531 . mls_compute_sid()
> did a linear search over the range transition rules and was therefore
> slow, but more recent kernels use a hash table so this problem has been
> solved. Another offender is sidtab_search_context() used to convert a
> SELinux context back into an sid, which is also a linear search as there
> is only a sid => context hash table, and I haven't seen any recent
> changes in this area.
>
> Please CC me as I'm not subscribed.
>
> r6144
>
--
ak@linux.intel.com -- Speaking for myself only.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-11-17 11:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-15 3:52 Sluggishness on a GEM system due to SELinux's sidtab_search_context() as well as get_unmapped_area() r6144
2010-11-17 11:43 ` Andi Kleen [this message]
2010-11-17 11:43 ` Andi Kleen
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=87tyjgqioi.fsf@basil.nowhere.org \
--to=andi@firstfloor.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rainy6144@gmail.com \
--cc=sds@tycho.nsa.gov \
/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.