From 95878586ec7611791f4001a4ee17abf943fae3c1 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14" Date: Mon, 16 Feb 2015 20:08:03 +0100 Subject: rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn --- .../pfinet_timers.mdwn | 177 +++++++++++++++++++++ 1 file changed, 177 insertions(+) create mode 100644 service_solahart_jakarta_selatan__082122541663/pfinet_timers.mdwn (limited to 'service_solahart_jakarta_selatan__082122541663/pfinet_timers.mdwn') diff --git a/service_solahart_jakarta_selatan__082122541663/pfinet_timers.mdwn b/service_solahart_jakarta_selatan__082122541663/pfinet_timers.mdwn new file mode 100644 index 00000000..244ca98b --- /dev/null +++ b/service_solahart_jakarta_selatan__082122541663/pfinet_timers.mdwn @@ -0,0 +1,177 @@ +[[!meta copyright="Copyright © 2013, 2014 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]]."]]"""]] + +[[!tag open_issue_hurd]] + + +# IRC, freenode, #hurd, 2013-02-11 + + now that there is a pthread_hurd_cond_timedwait_np function + available, we could replace the ulgy timers in pfinet + + +# IRC, freenode, #hurd, 2013-04-02 + + youpi: also, i think i know why fakeroot is slow on the hurd + well, pfinet actually + tcp flow control? + i think it's because of our timer resolution + ah + and i think i spotted a small mistake in the timer emulation code + btw + it's so obvious i even doubt it's actually true :) + see timer_emul.c:timer_function + the code checks for timers->expires < jiffies + shouldn't it be "<=" + ? + well it'd be equivalent + if ==, then wait becomes 0 in the else + see the second scheck + the one performed right before running the callback + ah, the while? + yes + I'd say <= could do it yes + ok + i have hurd packages ready to be tested + although I'm unsure it'd make a difference + do you notice some? + just waiting for my current glibc to finish building + and i'll test right after + i think it would actually + in which case? + the timer resolution is 10ms + it's huge + well, i hope it fixes fakeroot slowness :) + so timers below that would trigger immediately? + or equal + taht's the problem + for 10ms, timers that have expired must wait for the next tick to + fire + I include "equal" in below + actually :) + then yes :) + soryy i never know when equal is implicit + because they boil down to expires = jiffies + in french it's implicit + but anyway here equal is not really important + right + why ? + it's the fact that 1ms would be rounded up to 10ms, not down to 0ms + well, doing that seems reasonable + or rather, rounded down to 0ms, but waited for 10ms because of the + < + we do want timers not to fire before the time event + I'm however wondering which part of the code would have timer below + 10ms + well, a select with low timeout from a client perhaps ? + but then we have to round up + as you say we don't want to fire before some time + well yes + that's fine + all that being said, linux has been having 10ms clock for a long + time + but when the timer fires, i.e. when expires == jiffie, we do want + it to fire + highres timers are only relativeley recent + not at jiffie + 1 + braunr: ah, right, so we don't wait for 20ms instead of 10ms + yes + ok, so it's not a miracle fix, but could bring 2times fix + well, pfinet eats 40% of my processor when this problem occurs + which i'm seeing right now + yes, I've seen that too + so it may be a visible win + build finished :) let's see + Mmm, thinking again + indeed + when expires become jiffies + we mach_msg (0) + but don't do anything + and then restart + so just eaten cpu for nothing + is there a small package that builds fast and uses fakeroot a lot + ? + something like a package which has a lot of data to install at make + install + or i can rebuild glibc with -nc + ok, I've checked in linux + libarchive's testsuite used to intermittently failing under + fakeroot + it's definitely <= which is meant + it looks better + but still not 100% cpu + at any rate, as long as it doesn't seem to break anything, please + push the fix + it definitely makes sense + (and I don't see why it could break anything) + ok + i'll look into this timer problem a bit more, there may be other + code involved + yes, schedule_timeout could need a review + actually, fakeroot rm -rf * is a good test + and it's still damn slow + + +## IRC, freenode, #hurd, 2013-11-04 + + i think i know why fakeroot is slow no + now + schedule_timeout as implemented in pfinet can only be awaken by a + timeout + even when the expected even comes in earlier + so yes, the proper solution is to rewrite the timers using + interruptible_sleep_on_timeout (and in turn + pthread_hurd_cond_timedwait_np) + hm no, it's still not that straightforward :( + + +## IRC, freenode, #hurd, 2013-11-05 + + youpi: i found the bug slowing down fakeroot-tcp + it's actually a bug that slows down anything using the loopback + device + (although there still is a problem with fakeroot chown) + oh! + basically + the loopback device calls netif_rx from its xmit function + which is perfectly fine + except the glue code makes mark_bh (used to raise bottom halves) + broadcast a condition + and since netif_rx is called from within xmit, which is called + from the net_bh worker thread + the thread itself is never waiting for the condition when it is + broadcast + it's very simple to fix, i'll send a patch later + netcat to netcat now consumes 100% cpu + as does fakeroot ls -Rl + but for some reason fakeroot chown is still extremely slow + and i've seen deadlocks in glibc (e.g. setlocale() getting the + locale lock, which is locked again in case libfakeroot fails and calls + strerror) + so still a bit of debugging work needed + + +## IRC, freenode, #hurd, 2013-11-06 + + chown being slow with fakeroot-tcp can also be seen on linux + + did your recent patch improve the performance of fakeroot-tcp ? + yes + very nice :) + but fakeroot chown is still slow + although it's also slow on linux + so i'm not looking into that any more for the time being + as long as it's not used recursively on huge directories, it's + fine + + +## IRC, freenode, #hurd, 2013-11-09 + + braunr: fakeroot-tcp is indeed much faster now :) -- cgit v1.2.3