From 49a086299e047b18280457b654790ef4a2e5abfa Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 18 Feb 2015 00:58:35 +0100 Subject: Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn" This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1. --- .../time.mdwn | 853 --------------------- 1 file changed, 853 deletions(-) delete mode 100644 service_solahart_jakarta_selatan__082122541663/time.mdwn (limited to 'service_solahart_jakarta_selatan__082122541663/time.mdwn') diff --git a/service_solahart_jakarta_selatan__082122541663/time.mdwn b/service_solahart_jakarta_selatan__082122541663/time.mdwn deleted file mode 100644 index d9f1fa1d..00000000 --- a/service_solahart_jakarta_selatan__082122541663/time.mdwn +++ /dev/null @@ -1,853 +0,0 @@ -[[!meta copyright="Copyright © 2009, 2011, 2013 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_porting]] - -[[!toc]] - - -# `time` - -Neither the `time` executable from the GNU time package work completely -correctly, nor does the GNU Bash built-in one. - - tschwinge@flubber:~ $ \time sleep 2 - 0.00user 0.00system 9:38:00elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k - 0inputs+0outputs (0major+0minor)pagefaults 0swaps - tschwinge@flubber:~ $ \time sleep 4 - 0.00user 0.00system 18:50:25elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k - 0inputs+0outputs (0major+0minor)pagefaults 0swaps - tschwinge@flubber:~ $ \time sleep 6 - 0.00user 0.00system 28:00:53elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k - 0inputs+0outputs (0major+0minor)pagefaults 0swaps - tschwinge@flubber:~ $ time sleep 2 - - real 0m2.093s - user 0m0.000s - sys 0m0.011s - tschwinge@flubber:~ $ time sleep 4 - - real 0m4.083s - user 0m0.000s - sys 0m0.010s - tschwinge@flubber:~ $ time sleep 6 - - real 0m6.164s - user 0m0.000s - sys 0m0.010s - -GNU time's *elapsed* value is off by some factor. - - $ \time factor 1111111111111111111 - 1111111111111111111: 1111111111111111111 - 0.00user 0.00system 52:39:24elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k - 0inputs+0outputs (0major+0minor)pagefaults 0swaps - $ time factor 1111111111111111111 - 1111111111111111111: 1111111111111111111 - - real 0m11.424s - user 0m0.000s - sys 0m0.010s - -As above; also here all the running time should be attributed to *user* time. -This is probably a [[!taglink open_issue_gnumach]]. - - -## 2011-09-02 - -Might want to revisit this, and take Xen [[!tag open_issue_xen]] into account --- I believe flubber has already been Xenified at that time. - - -### IRC, freenode, #hurd, 2011-09-02 - -While testing some [[performance/IPC_virtual_copy]] performance issues: - - And I can confirm that with dd if=/dev/zero of=/dev/null bs=4k - running, a parallel sleep 10 takes about 20 s (on strauss). - -## 2013-03-30/31 - -Investigating time's `configure`, a difference of the output between Linux and -Hurd shows: - - -checking for wait3 that fills in rusage... yes - +checking for wait3 that fills in rusage... no - -This causes a different code path in `resuse.c` to be used; such code path does -not get a define for `HZ`, which is then defined with a fallback value of 60. - -[[!debbug 704283]] has been filed with a fix for this no-wait3 case. - - -# `times` - -## guile - -### IRC, freenode, #hurd, 2013-08-21 - - does guile2 on hurd fixed? times issue - nalaginrut: does not look good - scheme@(guile-user)> (times) - $1 = #(0 0 0 0 0) - well, seems not a fixed version, if there's fixed version - since it's not Guile's bug, I can do nothing for it - ah - in spite of this, Guile2 works I think - all tests passed but 2 fail - one of the failure is version shows "UNKNOWN" which is - trivials - well, did you try to fix the times issue in Hurd? - I didn't , I have to get more familiar with hurd first - I'm playing hurd these days - :) - anyway, I think times issue is beyond my ability at present - ;-P - times is implemented in the glibc, in sysdeps/mach/hurd/times.c - don't say that before you had a look - yes, you're right - but I think times has something to do with the kernel time - mechanism, dunno if it's related to the issue - how did you get the times.c under hurd? - apt-get source glibc? - well, I'd clone git://sourceware.org/git/glibc.git - and yes, the kernel is involved - task_info is used to obtain the actual values - - http://www.gnu.org/software/hurd/gnumach-doc/Task-Information.html - I'd guess that something fails, but the times(2) interface is - not able to communicate the exact failure - maybe it's not proper to get src from upstream git? since it's - OK under Linux which uses it too - but apt-get source glibc has nothing - so I would copy the times(2) implementation from the libc so - that you can modify it and run it as a standalone program - well, the libc has system dependent stuff, times(2) on Linux is - different from the Hurd version - it has to be - alright, I got what you mean ;-) - and the debian libc is built from the eglibc sources, so the - source package is called eglibc iirc - ah~I'll try - have you tried to rpctrace your times test program? the small c - snippet you posted the other day? - I haven't build all the tools & debug environment on my hurd - ;-( - what tools? - well, I don't even have git on it, and I'm installing but - speed is slow, I'm looking for a new mirror - ah well, no need to do all this on the Hurd directly - building the libc takes like ages anyway - oops ;-) - I'll take your advice to concentrate on times.c only - oh well, it might be difficult after all, not sure though - times sends two task_info messages, once with TASK_BASIC_INFO, - once with TASK_THREAD_TIMES_INFO - here is the relevant rpctrace of your test program: - task131(pid14726)->task_info (1 10) = 0 {0 25 153427968 643072 0 - 0 0 0 1377065590 570000} - task131(pid14726)->task_info (3 4) = 0 {0 0 0 10000} - ok, I don't know enough about that to be honest, but - TASK_THREAD_TIMES_INFO behaves funny - I put a sleep(1) into your test program, and if I rpctrace it, - it behaves differently o_O - * nalaginrut is reading task-information page to get what it could be - maybe I have to do the same steps under Linux to find some - clue - no, this is Mach specific, there is no such thing on Linux - on Linux, times(2) is a system call - on Hurd, times is a function implemented in the libc that - behaves roughly the same way - OK~so different - look at struct task_basic_info and struct task_thread_times_info - in the task-information page for the meaning of the values in the - rpctrace - yes, very - nalaginrut: you may want to try a patch i did but which is still - waiting to be merged in glibc - braunr: ah~thanks for did it ;-) - can I have the link? - i'm getting it - teythoon: funny things happen with rpctrace, that's expected - keep in mind rpctrace doesn't behave like ptrace at all - it acts as a proxy - nalaginrut: - http://git.savannah.gnu.org/cgit/hurd/glibc.git/commit/?h=rbraun/getclktck_100_hz&id=90404d6d1aa01f6ce1557841f5a675bb6a30f508 - nalaginrut: you need to add it to the debian eglibc patch list, - rebuild the packages, and install the resulting .debs - if you have trouble doing it, i'll make packages when i have time - braunr: I think your test result is expected? ;-) - what test result ? - times test under that patch - yes - but i have no idea if it will work - my patch fixes a mismatch between glibc and the procfs server - nothing more - it may help, it may not, that's what i'd like to know - hah~thanks for that - I get source from apt-get, then manually modified the files, - no much code ;-) - compiling - there is no cpuinfo in /proc? - no - a feature need to be done? or there's another way for that? - well, it hasn't been implemented - do you need that? what for? - compiling error, I realized I should use gcc-4.7 - how are you building? - I just happened to play proc while compiling, and found - there's no - cxa_finalize.c:48:1: error: ‘tcbhead_t’ has no member - named ‘multiple_threads’ - I changed to gcc-4.7 - just edit the sources, and then dpkg-buildpackage -nc -us -uc - that will rebuild the debian package as it would be in a debian - build, making sure all the build dependencies are there, etc - doing it different than that is just wrong™ - ok, doing - were you really doing ./configure etc yourself? - well, I can't wait till it's done, I'll let it compile and - check it out tomorrow - I used configure, yes ;-P - not good - I have to go, thanks for help guys - - -### IRC, freenode, #hurd, 2013-08-22 - - < nalaginrut> eglibc was done by dpkg-buildpackage, then how to install it? - (sorry I'm a brand new debian users) - < nalaginrut> oh~I found it - < nalaginrut> yes, (times) returns reasonable result ;-) - * nalaginrut is trying 'make check' - < nalaginrut> unfortunately, it can't pass the test though, I'm researching - it, anyway, we made first step - < nalaginrut> for Hurd internal-time-units-per-second will be 1000 - < nalaginrut> , but the elapsed time is far larger than (* 2 - internal-time-units-per-second) - < nalaginrut> I think the different of two returned clocks after 1 second - should be the TIME_UNITS_PER_SECOND, in principle - < nalaginrut> but I'm not sure if it's elibc or Guile bug - < nalaginrut> dunno, maybe clock tick should be 1000? - < nalaginrut> well, I'll try clock per second as 1000 - < braunr> nalaginrut: clock tick (or actually, the obsolete notion of a - clock tick in userspace) should be 100 - < braunr> nalaginrut: how did you come with 1000 ? - < nalaginrut> braunr: Guile set TIME_UNITS_PER_SECOND to 1000 when there's - no 8bytes size and doesn't define HAVE_CLOCK_GETTIME - < nalaginrut> #if SCM_SIZEOF_LONG >= 8 && defined HAVE_CLOCK_GETTIME - < nalaginrut> #define TIME_UNITS_PER_SECOND 1000000000 - < nalaginrut> #else - < nalaginrut> #define TIME_UNITS_PER_SECOND 1000 - < nalaginrut> #endif - < nalaginrut> and the test for 'times' used time-units-per-second - < pinotree> what has sizeof(long) have to do with time units per second? - < nalaginrut> dunno, maybe the representation of time? - < nalaginrut> the test failed since the difference between two clocks after - 1sec is too large - < nalaginrut> and for the test context, it should small than 2 times of - units-per-second - < nalaginrut> should be smaller - < nalaginrut> sorry for bad English - < pinotree> aren't you basically looking for clock_getres? - < nalaginrut> pinotree: I don't understand what you mean - < pinotree> - http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html - < nalaginrut> I wonder if there's a standard CLK_PER_SEC for Hurd - < nalaginrut> or it can be modified as wish - < pinotree> why do you need it? - < nalaginrut> the difference is 10,000,000, which can never less than - 2*clock_per_second - < nalaginrut> pinotree: I don't need it, but I want to know if there's a - standard value - < braunr> nalaginrut: ok so, this is entirely a guile thing - < braunr> nalaginrut: did you test with my patch ? - < nalaginrut> braunr: yes, 'times' works fine - < braunr> but even with that, a tets fails ? - < braunr> test* - < nalaginrut> well, I can't say works fine, the proper description is "now - it has reasonable result" - < braunr> youpi: could you bring - http://darnassus.sceen.net/gitweb/savannah_mirror/glibc.git/commit/90404d6d1aa01f6ce1557841f5a675bb6a30f508 - into debian glibc btw ? - < nalaginrut> braunr: it failed the test since the clock run too fast, but - it should be smaller than 2*clk-per-sec - < braunr> i don't get that - < braunr> can you show the code that checks the condition ? - < nalaginrut> braunr: http://pastebin.com/sG3QxnPt - < braunr> * 0.5 internal-time-units-per-second ? - < nalaginrut> for C users, it's just like - a=times(...);sleep(1);b=times(...); then time-units-per-sec/2 <= (b-a) <= - time-units-per-sec*2 - < braunr> ah ok - < nalaginrut> the test passes when it's true - < braunr> so basically, it says sleep(1) sleeps for more than 2 seconds - < braunr> can you check the actual value ? - < braunr> b-a - < nalaginrut> hold on for minutes - < nalaginrut> it's 10,000,000 - < nalaginrut> for clk-per-sec=1000,000,000, it's OK - < nalaginrut> but for 100 or 1000, it's too small - < braunr> let's forget 100 - < braunr> guile uses 1000 - < nalaginrut> OK - < braunr> but i still don't get why - < nalaginrut> so I asked if there's standard value, or it can be ajustified - < nalaginrut> adjusted - < braunr> ok so, times are expressed in clock ticks - < braunr> are you sure you're using a patched glibc ? - < nalaginrut> yes I used your patch, and the 'times' get reasonable result - < braunr> then - < braunr> 11:28 < nalaginrut> it's 10,000,000 - < braunr> doesn't make sense - < nalaginrut> hmm - < braunr> anhd i don't understand the test - < braunr> what's tms:clock new ? - < nalaginrut> it's actually the return value of 'times' - < nalaginrut> Guile wrap the clock_t and tms to a vector, then we can get - all the thing in a row - < nalaginrut> 'new' is a variable which was gotten after 1 sec - < braunr> let's see what this does exactly - < nalaginrut> equal to "new = times(...)" - < nalaginrut> 'tms' equal to (clock_t (struct tms)) - < nalaginrut> we have to pass in the struct pointer to get the struct - values filled, but for Guile we don't use pointer, times actually returns - two things: clock_t and struct tms - < nalaginrut> and Guile returns them as a vector in a row, that's it - < braunr> nalaginrut: test this please: - http://darnassus.sceen.net/~rbraun/test.c - < braunr> i don't have a patched libc here - < braunr> i'll build one right now - < nalaginrut> clock ticks: 1000000 - < braunr> and this seems reasonable to you ? - < braunr> anyway, i think the guile test is bugged - < nalaginrut> no, the reasonable is not for this - < braunr> does it ever get the clock tick value from sysconf() ? - < nalaginrut> I say reasonable since it's always 0 both for clock and tms, - before apply your patch - < braunr> uh no - < braunr> i have the same value, without my patch - < nalaginrut> so I said "I can't say it works fine" - < braunr> either the test is wrong because it doesn't use sysconf() - < nalaginrut> anyway, I don't think times should return "all zero" - < braunr> or the clock values have already been ocnverted - < braunr> but it doesn't - < braunr> you did something wrong - < nalaginrut> with your patch it doesn't - < braunr> without neither - < braunr> 11:43 < braunr> i have the same value, without my patch - < nalaginrut> well, it's too strange - < braunr> check how the test actually gets the clock values - < braunr> also, are your running in vbox ? - < braunr> you* - < nalaginrut> no ,it's physical machine - < braunr> oh - < braunr> nice - < braunr> note that vbox has timing issues - < nalaginrut> I thought I should give you some info of CPU, but there's no - /proc/cpuinfo - < braunr> shouldn't be needed - < nalaginrut> OK - < braunr> run my test again with an unpatched glibc - < braunr> just to make sure it produces the same result - < braunr> and - < nalaginrut> so the clock-per-sec is machine independent for Hurd I think - < braunr> 11:46 < braunr> check how the test actually gets the clock values - < nalaginrut> since it's implemented in userland - < braunr> clock-per-sec is always system dependent - < braunr> All times reported are in clock ticks. - < braunr> The number of clock ticks per second can be obtained - using: - < braunr> sysconf(_SC_CLK_TCK); - < braunr> 11:46 < braunr> check how the test actually gets the clock values - < braunr> to see if they're converted before reaching the test code or not - * nalaginrut is building eglibc - < braunr> building ? - < braunr> what for ? - < nalaginrut> I modified it to 1000, now it's useless - < braunr> we want it to 100 either way - < nalaginrut> and how to reinstall eglibc under debian? - < braunr> it's obsolete, procfs already uses 100, and 100 is low enough to - avoid overflows in practically all cases - < braunr> aptitude install libc0.3= - < nalaginrut> OK - < braunr> aptitude show -v libc0.3 - < braunr> for the list of available versions - < nalaginrut> out of topic, what's the meaning of the code in - quantize_timeval ? - < nalaginrut> tv->tv_usec = ((tv->tv_usec + (quantum - 1)) / quantum) * - quantum; - < nalaginrut> I can't understand this line - < braunr> scaling and rounding i guess - < nalaginrut> hmm...but quantum seems always set to 1? - < nalaginrut> 100/__getclktck() - < braunr> ah right - < braunr> old crap from the past - < nalaginrut> and clk-tck is 100 - < braunr> the author probably anticipated clk_ticks could vary - < braunr> in practice it doesn't, and that's why it's been made obsolete - < nalaginrut> I wonder if it could be vary - < braunr> no - < nalaginrut> alright - < nalaginrut> why not just assign it to 1? - < braunr> 11:55 < braunr> old crap from the past - < braunr> the hurd is 20 years old - < braunr> like linux - < nalaginrut> oh~ - < braunr> but with a lot less maintenance - < nalaginrut> braunr: well, I tried the original eglibc, your test was - clock ticks: 1000000 - < nalaginrut> but in Guile, (times) ==> (0 0 0 0 0) - < nalaginrut> the reasonable result maybe: #(4491527510000000 80000000 0 0 - 0) - < braunr> 11:46 < braunr> check how the test actually gets the clock values - < braunr> ah, he left - - -### IRC, freenode, #hurd, 2013-08-23 - - < braunr> nalaginrut: times() doesn't seem to be affected by my patch at - all - < nalaginrut> braunr: but it did in my machine - < nalaginrut> well, I think you mean it doesn't affect your C test code - < braunr> i'm almost sure something was wrong in your test - < braunr> keep using the official debian glibc package - < nalaginrut> I don't think it's test issue, since every time (times) - return zero, the test can never get correct result - < braunr> times doesn't return 0 - < braunr> for sleep(1), i always have the right result, except in - microseconds - < nalaginrut> times in Guile always return #(0 0 0 0 0) - < braunr> (microseconds is the native mach time unit) - < braunr> well, guile does something wrong - < nalaginrut> after sleep 1, it's 0 again, so it's none sense - < braunr> 11:46 < braunr> check how the test actually gets the clock values - < braunr> not on my system - < nalaginrut> but (times) returns reasonable result after applied your - patch - < braunr> that's not normal, since times isn't affected by my patch - < nalaginrut> oops - < braunr> you need to look for what happens in guile between the times() - call and the #(0 0 0 0 0) values - < nalaginrut> well, I tried many times between patch or non-patch, I think - there's no mistake - < nalaginrut> I read the 'times' code in Guile, there's nothing strange, - just call 'times' and put all the result to a vector - < braunr> which means there is no conversion - < braunr> in which case the test is plain wrong since there MUST also be a - call to sysconf() - < braunr> to obtain the right clock ticks value - < braunr> is your box reachable with ssh ? - < nalaginrut> oh~wait, seems there's a quotient operation, I'm checking - < nalaginrut> factor = scm_quotient (scm_from_long (TIME_UNITS_PER_SECOND), - < nalaginrut> scm_from_long (ticks_per_second)); - < braunr> iirc, TIME_UNITS_PER_SECOND is hardcoded - < nalaginrut> unless factor is zero - < nalaginrut> yes, it's hardcoded - < braunr> that's completely non portable and wrong - < nalaginrut> you suggest to call sysconf? - < braunr> yes - < braunr> but i don't have the code in mind - < braunr> what is ticks_per_second ? - < nalaginrut> OK, that's one issue, we have to find why times return 0 - < braunr> 14:14 < braunr> is your box reachable with ssh ? - < braunr> i'd like to make sure times returns 0 at your side - < braunr> because it doesn't at mine - < nalaginrut> no - < braunr> until i can reproduce, i can't consider there is a problem - < nalaginrut> I think it's unreachable for outer space - < nalaginrut> well, if you want to reproduce, just get guile src of debian - < braunr> guile 2.0 ? - < nalaginrut> yes, apt-get source guile-2.0 - < nalaginrut> I'm checking ticks_per_second - < braunr> got the source, how do i test - < braunr> ? - < nalaginrut> you have to build it, and run ./meta/guile, then you don't - have to install it - < nalaginrut> and try (times) - < braunr> aw libgc - < nalaginrut> the reasonable result should be #(4313401920000000 110000000 - 20000000 0 0) or something alike - < nalaginrut> but #(0 0 0 0 0) in each time is not reasonable apparently - < nalaginrut> maybe you need apt-get build-dep guile-2.0? - < braunr> already done - < nalaginrut> building Guile2 may take very long time - < nalaginrut> about 30 minutes in my old machine - < braunr> then it should take just a few minutes on mine - < nalaginrut> alright it's not very long, I've spent 8 hours for gcc in LFS - < braunr> 8 hours ? - < braunr> takes 5-10 minutes on a common machine .. - < nalaginrut> but it's Celeron566 at that time... - < braunr> ah, that old - < nalaginrut> include bootstrap, so very long - < braunr> nalaginrut: i got the test failure from the build procedure, how - do i run it manually ? - < nalaginrut> braunr: ./meta/guile -L test-suite - test-suite/tests/time.test - < nalaginrut> braunr: or make check for all - < braunr> put a print after the schedule() and before the return nil; in - runtime_mstart, since that's the body of new threads - < nlightnfotis> unfortunately, I can't confirm this with goroutines - running; the assertion failure aborts before I can get anything useful - < braunr> you can - < braunr> make sure there is a \n in the message, since stdout is line - buffered by default - < braunr> if you don't reach that code, it means threads don't exit - < braunr> at least goroutine threads - < braunr> btw, where is the main thread running ? - < nlightnfotis> I just checked there is a \n at the end. - < nlightnfotis> " btw, where is the main thread running " could you - elaborate a little bit on this? - < braunr> what does main() after initializing the runtime ? - < braunr> +do - < nlightnfotis> the runtime main or the process's main? - < braunr> the process - < braunr> nlightnfotis: what we're interested in is knowing whether main() - exits or not - < nlightnfotis> braunr: I can see there are about 4 functions of interest: - runtime_main (the main goroutine, and I can imagine 1st thread) - < nlightnfotis> main_init (I don't know what it does, will check this out - now) - < nlightnfotis> main_main (not sure about this one either) - < nlightnfotis> and runtime_exit (0) - < braunr> i can see that too - < braunr> i'm asking about main() - < nlightnfotis> which seems to be the function that terminates the main - thread - < nlightnfotis> nlightnfotis: what we're interested in is knowing - whether main() exits or not --> my theory is runtime_exit (0) exits the - process' main. Seeing as at various times go programs echo $? == 0. - < nlightnfotis> let me research that a little bit - < nlightnfotis> braunr: that will require a bit more studying. main_main() - and main_init() are both expanded to assembly tags if I understand it - correctly. - < nlightnfotis> main.main and __go_init_main respectively. - < braunr> why are you looking from there instead of looking from main() ? - < nlightnfotis> are we not looking out if main exits? - < braunr> we are - < braunr> so why look at main_main ? - < braunr> or anything else than main ? - < nlightnfotis> these are called inside runtime_main and I figured out they - might have a clue - < braunr> runtime_main != main - < braunr> (except if there is aliasing) - < nlightnfotis> there is still the possibility that runtime_main is the - main function and that runtime_exit(0) exits it. - < braunr> there is no doubt that main is main - < braunr> (almost) - < nlightnfotis> and I just found out that there is no main in assembly - produced from go. Only main.main - < braunr> check the elf headers for the entry point then - < nlightnfotis> braunr: I went through the headers, and found the process' - main. You can find it in /libgo/runtime/go-main.c - < nlightnfotis> it seems very strange though: It creates a new thread, then - aborts? - < braunr> nlightnfotis: see :) - < braunr> nlightnfotis: add traces there - < nlightnfotis> braunr: can you look into that piece of code to check out - something I don't understand? - < nlightnfotis> braunr: I can not seem able to find __go_go 's definition - < nlightnfotis> only a declaration in runtime.h - < braunr> - https://github.com/NlightNFotis/gcc/blob/master/libgo/runtime/proc.c, - line 1552 - < nlightnfotis> gee thanx. For a strange kind of fashion, I was looking for - it in runtime.c - < braunr> use git grep - < braunr> or tags/cscope - < nlightnfotis> braunr: yep! runtime_exit does seem to terminate a go - process that was not otherwise abnormally terminated. - < braunr> ? - < braunr> is it called or not ? - < braunr> runtime_exit is a macro on exit() - < braunr> so we already know what it does - < nlightnfotis> it is called - < braunr> ok - < braunr> that's not normal :) - < nlightnfotis> for a simple program - < braunr> uh ? - < nlightnfotis> for one that has a go routine - < braunr> but - < nlightnfotis> it doesn't - < nlightnfotis> it's expected - < braunr> ok - < braunr> that makes sense - < braunr> well, trace - < braunr> keep tracing - < braunr> for example in main() - < braunr> is runtime_mstart() actually reached ? - < nlightnfotis> yeah main and runtime_main were my next two targets - < braunr> good - < nlightnfotis> and now I followed your advice and it does compiler much - faster - < braunr> so, it looks like the main thread just becomes a mere kernel - thread - < braunr> running runtime_mstart() and fetching goroutines as needed - < braunr> after your traces, i'd suggest running a small go test program, - with one simple goroutine (doesn't crash right ?) - < braunr> and trace context switching - < braunr> but after the traces - < braunr> one important trace is to understand why runtime_exit gets called - < nlightnfotis> it does crash even with 1 goroutine - < braunr> oh - < braunr> when doesn't it crash ? - < nlightnfotis> when it has 0 goroutines - < nlightnfotis> it works as expected - < nlightnfotis> but anything involving goroutines crashes - < nlightnfotis> and goroutines are very important; everything in the - standard library involves goroutines - < braunr> ok - < braunr> doesn't change what i suggested, good - < braunr> 1/ find out why runtime_exit gets called - < braunr> 2/ trace context switching with 1 goroutine - < nlightnfotis> on it. - < braunr> in all cases, make all your goroutines (including the main one) - *not* return - < braunr> so that you don't deal with goroutine destruction yet - < nlightnfotis> runtime_mstart in main doesn't to be run at all. So the - path is __go_go and then return from it. - < nlightnfotis> *doesn't seem - - -### IRC, freenode, #hurd, 2013-08-26 - - < braunr> youpi: my glibc clock patch looks incomplete btw - < youpi> which one? - < youpi> ah, the ticks one? - < braunr> yes - < braunr> it doesn't change the values returned by times - < braunr> as a side effect, the load average bumps to 2+ on an idle machine - - -### IRC, freenode, #hurd, 2013-08-27 - - < nalaginrut> braunr: have you tried Guile2 on your machine? ;-) - < braunr> nalaginrut: no - < braunr> nalaginrut: but i saw the code actually does use sysconf() - < nalaginrut> braunr: yes, for ticks_per_second - < braunr> i had to look myself to find it out, you didn't say it, despite - me asking multiple times - < braunr> it won't make debugging easier ;p - < braunr> nalaginrut: also, the return value of times is actually *never* - used - < braunr> i don't know why you've been talking about it so much - < nalaginrut> braunr: I'm sorry, it's first time to look stime.c for me - < braunr> the interesting function is get_internal_run_time_times() - < nalaginrut> what do you mean about "the return value of times is actually - *never* used"? in which context? - < braunr> see get_internal_run_time_times - < braunr> struct tms time_buffer; - < braunr> times(&time_buffer); - < braunr> return ... - < braunr> and yes, the user and system time reported in struct tms are 0 - < braunr> let's see what posix has to say about it - < pinotree> it says it will return (clock_t)-1 for errors, but no standard - errors are defined yet - < nalaginrut> but I don't think get_internal_run_time_times has something - to do with scm_times - < braunr> well, i don't see any other call to times() - < braunr> i've asked you repeatedly to look for how guile fetches the data - < braunr> i think it's done in get_internal_run_time_times - < braunr> what makes you think otherwise ? - < braunr> our times() seems to behave fine, other than the units of the - return value - < nalaginrut> I don't understand what do you mean? - get_internal_run_time_times is unrelated to scm_times which is actually - "times" in Scheme code - < braunr> ok - < nalaginrut> I think we're talking about "times" activity, right? - < braunr> ok so result is a vector - < braunr> with the return value and the four values in struct tms - < nalaginrut> yes - < braunr> and what looks interesting is - < braunr> factor = scm_quotient (scm_from_long (TIME_UNITS_PER_SECOND), - scm_from_long (ticks_per_second)); - < braunr> SCM_SIMPLE_VECTOR_SET (result, 0, scm_product (scm_from_long - (rv), factor)); - < braunr> TIME_UNITS_PER_SECOND is 1000 - < nalaginrut> yes, it means (clock_t * - (TIME_UNITS_PER_SECOND/ticks_per_second)), though I've no idea why it - does this - < braunr> normalizing values i guess - < nalaginrut> I wonder if the factor should be 1, just guessing - < braunr> let's see what our clock tick really is - < braunr> 1000000 on an unmodified libc - < braunr> 100 with my patch - < nalaginrut> so what's the problem? - < nalaginrut> all the values were multiplied by ticks, it's fair for the - subtraction - < nalaginrut> I think the problem is clock is too large for the difference - between utime and utime(sleep 1) - < nalaginrut> oops, is too small - < nalaginrut> sorry, I confused, - < nalaginrut> the problem is the difference of clock is too large for - 2*internal-time-units-per-second - < nalaginrut> and actually, internal-time-units-per-second is - SCM_TIME_UNITS_PER_SECOND - < nalaginrut> but without your patch, 'times' would return zeros all the - time, which is never meet the condition: SCM_TIME_UNITS_PER_SECOND/2 <= - (clock2 - clock1) - < nalaginrut> well, maybe your point is - TIME_UNITS_PER_SECOND/ticks_per_second is too small without your patch, - which causes the scm_to_long cast give a 0 value - < nalaginrut> s/cast/casting - < nalaginrut> when ticks_per_second is 100, the factor would be 10, which - seems to be reasonable - < nalaginrut> s/scm_to_long/scm_from_long - < nalaginrut> well, I have to checkout this - < nalaginrut> OK, let me reconstruct the point: ticks_per_second so too - large that makes the factor becomes zero - < nalaginrut> but decrease ticks_per_second to 100 causes the clock become - too large than TIME_UNITS_PER_SECOND - < braunr> 10:59 < nalaginrut> but without your patch, 'times' would return - zeros all the time, which is never meet the condition: - SCM_TIME_UNITS_PER_SECOND/2 <= (clock2 - clock1) - < braunr> until you prove me otherwise, this is plain wrong - < braunr> times() never returned me 0 - < braunr> so let's see, this gives us a factor of 1000 / 1000000 - < braunr> so the problem is factor being 0 - < braunr> that's why *guile* times returns 0 - < braunr> with my patch it should return 10 - < nalaginrut> braunr: I'm sorry I mean "stime" in Scheme returns zeros - < nalaginrut> yes, I think the problem is factor - < nalaginrut> the factor - < braunr> now why doesn't my patch fix it all ? - < braunr> ah yes, rv is still in microseconds - < braunr> that's what i've been telling youpi recently, my patch is - incomplete - < braunr> i'll cook a quick fix, give me a few minutes please - < nalaginrut> but it fixed something ;-) - < braunr> well, guile makes a stupid assumption here - < braunr> so it's not really a fix - < nalaginrut> braunr: should I ask some info about TIME_UNITS_PER_SECOND - from Guile community? - < nalaginrut> or it doesn't help - < braunr> what do you want to ask them ? - < nalaginrut> since I don't know how this value was chosen - < nalaginrut> dunno, I'll ask if you need it - < nalaginrut> I just think maybe you need this info - < braunr> well - < braunr> my plan is to align the hurd on what other archs do - < braunr> i.e. set clk_tck to 100 - < braunr> in which case this won't be a problem any more - < braunr> now you could warn them about the protability issue - < braunr> i'm not sure if they would care though - < nalaginrut> the warning is useful for the future - < nalaginrut> and it's not hard to make a change I think, for a constant, - but it depends on the maintainers - < braunr> it's not that simple - < braunr> time related things can easily overflow in the future - < nalaginrut> alright - < braunr> refer to the 2038 end-of-the-world bug - < nalaginrut> so how can I describe the warning/suggestion to them? - < braunr> i'm not sure - < braunr> tell them the TIME_UNITS_PER_SECOND isn't appropriate for larger - values of clk_tck - < braunr> dammit, microseconds are hardcoded everywhere in - sysdeps/mach/hurd ... >( - < braunr> nalaginrut: my new patch seems to fix the problem - < braunr> nalaginrut: i've built debian packages with which you can - directly test - < braunr> nalaginrut: deb http://ftp.sceen.net/debian-hurd-i386 - experimental/ - < braunr> Totals for this test run: - < braunr> passes: 38605 - < braunr> failures: 0 - < braunr> unexpected passes: 0 - < braunr> expected failures: 7 - < braunr> unresolved test cases: 578 - < braunr> untested test cases: 1 - < braunr> unsupported test cases: 10 - < braunr> errors: 0 - < braunr> PASS: check-guile - < braunr> ============= - < braunr> 1 test passed - < braunr> ============= - < braunr> :) - < braunr> youpi: the branch i added to glibc contains a working patch for - clock_t in centiseconds - < youpi> k - - -### IRC, freenode, #hurd, 2013-08-28 - - braunr: well, looks great! I'll try it soon~ - braunr: BTW, where is the patch/ - braunr: what was needed to get guile working on the hurd? - well, if the fix wasn't to guile, I don't need the details. - 04:53 < nalaginrut> braunr: BTW, where is the patch/ - there is hardly anyone here at 5am - nalaginrut: - http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/clock_t_centiseconds - braunr: thanks for that, but why not use a constant for 100? - nalaginrut: i don't know where to define it - it's glibc, you don't define new stuff mindlessly - braunr: about your centiseconds patch, did you run the libc - testsuite with it? - it does seem a shame to reduce the resolution of the timers - from microseconds to centiseconds. I wonder if that could be avoided. - by fixing all applications which assume centiseconds - *nod* well, if there's such a problem in Guile, I'd be glad - to fix that. - youpi: no - I see that there's a macro CLOCKS_PER_SEC that programs - should consult. - braunr: ok, I'll do then - mark_weaver: why is it a shame ? - it's not clock or timer resolution - it's clock_t resolution - it's an obsolete api to measure average cpu usage - having such a big value on the other hand reduces the cpu usage - durations - braunr: good point :) I confess to being mostly ignorant of - these APIs. - Though Guile should still consult CLOCKS_PER_SEC instead of - assuming centiseconds. If it's making an improper assumption, I'd like - to know so I can fix it. - the improper assumption is that there are less than 1000 clock - ticks per second - do you know off-hand of some code in Guile that is making - improper assumptions? - yes - let me find it - thanks - factor = scm_quotient (scm_from_long (TIME_UNITS_PER_SECOND), - scm_from_long (ticks_per_second)); - it seems guile attempts to normalize all times values to - TIME_UNITS_PER_SECOND - while i think it would be better off using ticks_per_second (clock - ticks as provided by sysconf()) - attempting to normalize here causes factor to become 0 if - TIME_UNITS_PER_SECOND < ticks_per_second - ah, I see. - I'll take care of it. thanks for the pointer! - braunr: I've commited the centisecond patch to debian's glibc - - -### IRC, freenode, #hurd, 2013-08-29 - - braunr: Guile2 works smoothly now, let me try something cool - with it - nalaginrut: nice - - -### IRC, OFTC, #debian-hurd, 2013-09-29 - - youpi: is the latest glibc carrying the changes related to - timing? what about gb guile-2.0 with it? - it does - so that was the only issue with guile? - well at least we'll see - iirc yes - according to nalaginrut and the latest build log, it'd seem so - started - yay, guile-2.0 :) - yay -- cgit v1.2.3