From 2603401fa1f899a8ff60ec6a134d5bd511073a9d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 7 Aug 2012 23:25:26 +0200 Subject: IRC. --- open_issues/performance.mdwn | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) (limited to 'open_issues/performance.mdwn') 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. 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 + + there are several kinds of scalability issues + iirc, i found some big locks in core libraries like libpager and + libdiskfs + but anyway we can live with those + 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 + the mistake here is moving part of the pageout policy out of the + kernel + so it would require the kernel to handle periodic synces of the + page cache + braunr: as for big locks: considering that we don't have any SMP + so far, does it really matter?... + antrik: yes + we have multithreading + there is no reason to block many threads while if most of them + could continue + -while + so that's more about latency than throughput? + considering sleeping/waking is expensive, it's also about + throughput + 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) + ouch -- cgit v1.2.3