summaryrefslogtreecommitdiff
path: root/open_issues/performance.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/performance.mdwn')
-rw-r--r--open_issues/performance.mdwn29
1 files changed, 29 insertions, 0 deletions
diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn
index 8dbe1160..ec14fa52 100644
--- a/open_issues/performance.mdwn
+++ b/open_issues/performance.mdwn
@@ -52,3 +52,32 @@ call|/glibc/fork]]'s case.
<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