1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
|
[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
*Performance analysis* ([[!wikipedia Performance_analysis desc="Wikipedia
article"]]) deals with analyzing how computing resources are used for
completing a specified task.
[[Profiling]] is one relevant tool.
In [[microkernel]]-based systems, there is generally a considerable [[RPC]]
overhead.
In a multi-server system, it is non-trivial to implement a high-performance
[[I/O System|community/gsoc/project_ideas/disk_io_performance]].
When providing [[faq/POSIX_compatibility]] (and similar interfaces) in an
environemnt that doesn't natively implement these interfaces, there may be a
severe performance degradation. For example, in this [[`fork` system
call|/glibc/fork]]'s case.
[[Unit_testing]] can be used for tracking performance regressions.
---
* [[Degradation]]
* [[fork]]
* [[IPC_virtual_copy]]
* [[microbenchmarks]]
* [[microkernel_multi-server]]
* [[gnumach_page_cache_policy]]
* [[metadata_caching]]
---
# IRC, freenode, #hurd, 2012-07-05
<braunr> the more i study the code, the more i think a lot of time is
wasted on cpu, unlike the common belief of the lack of performance being
only due to I/O
## IRC, freenode, #hurd, 2012-07-23
<braunr> there are several kinds of scalability issues
<braunr> iirc, i found some big locks in core libraries like libpager and
libdiskfs
<braunr> but anyway we can live with those
<braunr> in the case i observed, ext2fs, relying on libdiskfs and libpager,
scans the entire file list to ask for writebacks, as it can't know if the
pages are dirty or not
<braunr> the mistake here is moving part of the pageout policy out of the
kernel
<braunr> so it would require the kernel to handle periodic synces of the
page cache
<antrik> braunr: as for big locks: considering that we don't have any SMP
so far, does it really matter?...
<braunr> antrik: yes
<braunr> we have multithreading
<braunr> there is no reason to block many threads while if most of them
could continue
<braunr> -while
<antrik> so that's more about latency than throughput?
<braunr> considering sleeping/waking is expensive, it's also about
throughput
<braunr> currently, everything that deals with sleepable locks (both
gnumach and the hurd) just wake every thread waiting for an event when
the event occurs (there are a few exceptions, but not many)
<antrik> ouch
|
