From 3ebdfe56c9cde5128b5f9da1be2f82104049fa7b Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 5 Nov 2011 15:06:52 +0100 Subject: contributing/web_pages: Savannah web pages repository. --- contributing/web_pages.mdwn | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/contributing/web_pages.mdwn b/contributing/web_pages.mdwn index d1b3c0fc..b2e96121 100644 --- a/contributing/web_pages.mdwn +++ b/contributing/web_pages.mdwn @@ -130,13 +130,22 @@ is also read-only. $ git clone http://www.bddebian.com:8888/git/hurd-web [dest] -For all cases: if you omit `[dest]` it will default to `hurd-web`. +Or, you can check out the Savannah repository: -Later, you can just `cd` into the `hurd-web` directory and run a `git pull` to -get hold of the latest changes others have been installing in the mean time. -(In most cases, you should use `git pull --rebase`, -to avoid useless *Merge branch ...* messages. See the -Git documentation for details.) + $ git clone git://git.savannah.gnu.org/hurd/web.git [dest] + +See . If you're using the `ssh` +protocol, and you're a member of the Hurd's [[rules/Savannah_group]], you can +also push to this repository. The disadvantage of pushing to the Savannah +repository is that there is no [[ikiwiki]] installation where the pushed +changes are immediatelly rendered and viewable by everyone. + +For all cases: if you omit `[dest]` it will default to `hurd-web` for the +`bddebian.com` repositories, or `web` for a Savannah clone. + +Later, you can just `cd` into the `hurd-web` or `web` directory, and, for +example, run `git pull` to get hold of the latest changes others have been +installing in the mean time. ## Editing the Content -- cgit v1.2.3 From 4cc3f682fb57a920e3cc14e99323d66e380c1ee7 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 5 Nov 2011 23:19:34 +0100 Subject: open_issues/performance/io_system/binutils_ld_64ksec: Move Xen lseek stuff... open_issues/xen_lseek: ... here. --- .../performance/io_system/binutils_ld_64ksec.mdwn | 23 +++------------------- open_issues/performance/io_system/test-lseek.c | 17 ---------------- open_issues/performance/io_system/test-mach.c | 19 ------------------ open_issues/xen_lseek.mdwn | 22 +++++++++++++++++++++ open_issues/xen_lseek/test-lseek.c | 17 ++++++++++++++++ open_issues/xen_lseek/test-mach.c | 19 ++++++++++++++++++ 6 files changed, 61 insertions(+), 56 deletions(-) delete mode 100644 open_issues/performance/io_system/test-lseek.c delete mode 100644 open_issues/performance/io_system/test-mach.c create mode 100644 open_issues/xen_lseek/test-lseek.c create mode 100644 open_issues/xen_lseek/test-mach.c diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn index d0b8ea7f..931fd0ee 100644 --- a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn +++ b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn @@ -27,10 +27,6 @@ extracted from cdf7c161ebd4a934c9e705d33f5247fd52975612 sources, 2010-10-24. On the idle grubber, this one repeatedly takes a few minutes wall time to complete successfully, contrary to a few seconds on a GNU/Linux system. -> On order of slowness may in fact be due to a Xen-specific issue, see -> [[xen_lseek]]. (But there are probably still one or two orders left, even -> without Xen.) - While processing the object files, there is heavy interaction with the relevant [[hurd/translator/ext2fs]] process. Running [[hurd/debugging/rpctrace]] on the testee shows that (primarily) an ever-repeating series of `io_seek` and @@ -38,19 +34,6 @@ the testee shows that (primarily) an ever-repeating series of `io_seek` and shows the equivalent thing (`_llseek`, `read`) -- but Linux' I/O system isn't as slow as the Hurd's. ---- - -IRC, freenode, #hurd, 2011-09-01: - - hum, f951 does myriads of 71->io_seek_request (32768 0) = 0 32768 - no wonder it's slow - unfortunately that's also what it does on linux, the system call is - just less costly - apparently gfortran calls io_seek for, like, every token of the - sourced file - (fgetpos actually, but that's the same) - and it is indeed about 10 times slower under Xen for some reason - -Also see testcase [[test-lseek.c]] and [[test-mach.c]] - -[[!tag open_issue_xen]] +As Samuel figured out later, this slowness may in fact be due to a Xen-specific +issue, see [[Xen_lseek]]. After the latter has been addressed, we can +re-evaluate this issue here. diff --git a/open_issues/performance/io_system/test-lseek.c b/open_issues/performance/io_system/test-lseek.c deleted file mode 100644 index 667dce66..00000000 --- a/open_issues/performance/io_system/test-lseek.c +++ /dev/null @@ -1,17 +0,0 @@ -#include -#include -#include -#include -#include -#define N 100000 -int main(void) { - int fd = open("test.c", O_RDONLY); - struct timeval tv1, tv2; - int i; - gettimeofday(&tv1, NULL); - for (i = 0; i < N; i++) - lseek(fd, 0, SEEK_CUR); - gettimeofday(&tv2, NULL); - printf("%fµs\n", (float)((tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec)/N); - return 0; -} diff --git a/open_issues/performance/io_system/test-mach.c b/open_issues/performance/io_system/test-mach.c deleted file mode 100644 index 90337346..00000000 --- a/open_issues/performance/io_system/test-mach.c +++ /dev/null @@ -1,19 +0,0 @@ -#define _GNU_SOURCE -#include -#include -#include -#define N 1000000 -int main(void) { - struct timeval tv1, tv2; - int i; - task_t task; - task = mach_task_self(); - mach_port_urefs_t refs; - gettimeofday(&tv1, NULL); - for (i = 0; i < N; i++) { - mach_port_get_refs(task, task, MACH_PORT_RIGHT_RECEIVE, &refs); - } - gettimeofday(&tv2, NULL); - printf("%fµs\n", (float)((tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec)/N); - return 0; -} diff --git a/open_issues/xen_lseek.mdwn b/open_issues/xen_lseek.mdwn index accc7c8f..756abf5e 100644 --- a/open_issues/xen_lseek.mdwn +++ b/open_issues/xen_lseek.mdwn @@ -10,6 +10,17 @@ License|/fdl]]."]]"""]] [[!tag open_issue_xen]] +IRC, freenode, #hurd, 2011-09-01: + + hum, f951 does myriads of 71->io_seek_request (32768 0) = 0 32768 + no wonder it's slow + unfortunately that's also what it does on linux, the system call is + just less costly + apparently gfortran calls io_seek for, like, every token of the + sourced file + (fgetpos actually, but that's the same) + and it is indeed about 10 times slower under Xen for some reason + IRC, freenode, #hurd, 2011-11-02: btw, we have a performance issue with xen @@ -33,3 +44,14 @@ IRC, freenode, #hurd, 2011-11-02: http://www.gnu.org/software/hurd/open_issues/performance/io_system/binutils_ld_64ksec.html [[performance/io_system/binutils_ld_64ksec]]. + +Also see the simple testcases [[test-lseek.c]] and [[test-mach.c]]. + +IRC, freenode, #hurd, 2011-11-05: + + [test-mach.c is] mostly as a reference for the trap overhead + 0.56µs (xen) vs 0.48µs(kvm) on test-mach + 455µs(xen) vs 16µs(kvm) on test-lseek + that might simply be an issue in the RPC mechanism, which behaves + badly with the xen memory management + yes, about 0.5ms for an lseek, that's quite high :) diff --git a/open_issues/xen_lseek/test-lseek.c b/open_issues/xen_lseek/test-lseek.c new file mode 100644 index 00000000..667dce66 --- /dev/null +++ b/open_issues/xen_lseek/test-lseek.c @@ -0,0 +1,17 @@ +#include +#include +#include +#include +#include +#define N 100000 +int main(void) { + int fd = open("test.c", O_RDONLY); + struct timeval tv1, tv2; + int i; + gettimeofday(&tv1, NULL); + for (i = 0; i < N; i++) + lseek(fd, 0, SEEK_CUR); + gettimeofday(&tv2, NULL); + printf("%fµs\n", (float)((tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec)/N); + return 0; +} diff --git a/open_issues/xen_lseek/test-mach.c b/open_issues/xen_lseek/test-mach.c new file mode 100644 index 00000000..90337346 --- /dev/null +++ b/open_issues/xen_lseek/test-mach.c @@ -0,0 +1,19 @@ +#define _GNU_SOURCE +#include +#include +#include +#define N 1000000 +int main(void) { + struct timeval tv1, tv2; + int i; + task_t task; + task = mach_task_self(); + mach_port_urefs_t refs; + gettimeofday(&tv1, NULL); + for (i = 0; i < N; i++) { + mach_port_get_refs(task, task, MACH_PORT_RIGHT_RECEIVE, &refs); + } + gettimeofday(&tv2, NULL); + printf("%fµs\n", (float)((tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec)/N); + return 0; +} -- cgit v1.2.3 From 21608c7e5aabb217977fd2db4657f28eae848d51 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 5 Nov 2011 23:44:32 +0100 Subject: hurd/libpthread.git ea6390b2f20a03b7d504bc68a1c95e645d271149 --- .../libpthread_pthread_key_create_reuse.mdwn | 66 +--------------------- .../pthread_key_create_reuse.c | 48 ---------------- 2 files changed, 1 insertion(+), 113 deletions(-) delete mode 100644 open_issues/libpthread_pthread_key_create_reuse/pthread_key_create_reuse.c diff --git a/open_issues/libpthread_pthread_key_create_reuse.mdwn b/open_issues/libpthread_pthread_key_create_reuse.mdwn index ca2da2f5..ea6a0abf 100644 --- a/open_issues/libpthread_pthread_key_create_reuse.mdwn +++ b/open_issues/libpthread_pthread_key_create_reuse.mdwn @@ -8,75 +8,11 @@ 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]]."]]"""]] -[[!meta title="libpthread: pthread_key_create, reuse"]] +[[!meta title="libpthread vs. licq"]] [[!tag open_issue_libpthread]] IRC, FreeNode, #hurd, 2011-07-02: - < pinotree> hm, maybe i found a libpthread bug - * pinotree tries a testcase - < pinotree> yesssss, found the bug :) - < pinotree> youpi: it's a problem of the key reuse in pthread_key_create() - < youpi> it doesn't reset it? - < youpi> were you looking at the licq issue? - < pinotree> no, gtest - < youpi> k < youpi> licq has a failing threadspecific issue < youpi> [ FAILED ] ThreadSpecificData.dataDeletedWhenThreadExits - < pinotree> basically, pthread_key_delete() does not delete the key values - from the "thread_specifics" ihash - < pinotree> but those were new keys, so i'm not sure it is allowed to - return values of previous keys? - < pinotree> after all, the actual key value is an implementation detail, - applications shouldn't care about it being reused - < pinotree> (imho) - < youpi> Upon key creation, the value NULL shall be associated with the new - key in all active threads. - < youpi> ok, so we have to clear it in all threads - < youpi> that's a pity - < pinotree> or just remove the entry from the hash on key removal - < youpi> pinotree: from all the hashes, you mean? - < pinotree> youpi: from how i see it, adding a snippet like - http://paste.debian.net/121690/ in pthread_key_delete() should do the job - < youpi> that only drops from the current thread - < pinotree> ah hm, other threads - < youpi> we need to drop from all threads - < youpi> that's the pity part - < pinotree> youpi: the licq case could look like a similar issue, at a - veeery quick glance - -Test program: [[pthread_key_create_reuse.c]] - - -2011-11-01: - - youpi: about the bug with pthread keys (reuse): would be an - acceptable solution having a mutex for the thread_specifics of each - thread? - you mean one per thread, one global, or one per key, or ? - what is it supposed to protect? - the thread_specifics of each thread - pinotree: but against what? - the idea would be: when destroying a key, iterate over all the - exiting threads and remove the key data from the thread_specifics of each - thread - one of the issue is getting to browse through the whole list of - threads - the other is concurrency between that, and a thread dying - there's the __pthread_threads_lock rwlock - it should be enough to keep it locked during the iteration - but that wouldn't be enough when one thread is destroying a key, - and another one is doing {get,set}specific() on that key - that's not supposed to happen - mmm - “The effect of calling pthread_getspecific() or - pthread_setspecific() with a key value not obtained from - pthread_key_create() or after key has been deleted with - pthread_key_delete() is undefined.” - undefined -> you are allowed to just blow up - but it's not been deleted yet... :) - it could be, just a matter of time - you're not supposed to rely on time-luckyness :) - mmm - bah, you've convinced me ( :) ) diff --git a/open_issues/libpthread_pthread_key_create_reuse/pthread_key_create_reuse.c b/open_issues/libpthread_pthread_key_create_reuse/pthread_key_create_reuse.c deleted file mode 100644 index f7f5874e..00000000 --- a/open_issues/libpthread_pthread_key_create_reuse/pthread_key_create_reuse.c +++ /dev/null @@ -1,48 +0,0 @@ -#include -#include -#include - -#define DEBUG - -void del(void *x __attribute__((unused))) -{ -} - -void work(int val) -{ - pthread_key_t key1; - pthread_key_t key2; - -#ifdef DEBUG - printf("work/%d: start\n", val); -#endif - assert(pthread_key_create(&key1, &del) == 0); - assert(pthread_key_create(&key2, &del) == 0); -#ifdef DEBUG - printf("work/%d: pre-setspecific: %p,%p\n", val, pthread_getspecific(key1), pthread_getspecific(key2)); -#else - assert(pthread_getspecific(key1) == NULL); - assert(pthread_getspecific(key2) == NULL); -#endif - assert(pthread_setspecific(key1, (void *)(0x100 + val)) == 0); - assert(pthread_setspecific(key2, (void *)(0x200 + val)) == 0); -#ifdef DEBUG - printf("work/%d: post-setspecific: %p,%p\n", val, pthread_getspecific(key1), pthread_getspecific(key2)); -#else - assert(pthread_getspecific(key1) == (void *)(0x100 + val)); - assert(pthread_getspecific(key2) == (void *)(0x200 + val)); -#endif - assert(pthread_key_delete(key1) == 0); - assert(pthread_key_delete(key2) == 0); -} - -int main() -{ - int i; - - for (i = 0; i < 8; ++i) { - work(i + 1); - } - - return 0; -} -- cgit v1.2.3 From e0d7f527ef47be4da27c3dbf32db8756fa5449f9 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 6 Nov 2011 10:56:44 +0100 Subject: hurd/libpthread.git 76af844177c2bacd7a39e865cf0bbe484a68ddb8 --- open_issues/libpthread_pthread_key_create_reuse.mdwn | 18 ------------------ 1 file changed, 18 deletions(-) delete mode 100644 open_issues/libpthread_pthread_key_create_reuse.mdwn diff --git a/open_issues/libpthread_pthread_key_create_reuse.mdwn b/open_issues/libpthread_pthread_key_create_reuse.mdwn deleted file mode 100644 index ea6a0abf..00000000 --- a/open_issues/libpthread_pthread_key_create_reuse.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -[[!meta copyright="Copyright © 2011 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]]."]]"""]] - -[[!meta title="libpthread vs. licq"]] - -[[!tag open_issue_libpthread]] - -IRC, FreeNode, #hurd, 2011-07-02: - - < youpi> licq has a failing threadspecific issue - < youpi> [ FAILED ] ThreadSpecificData.dataDeletedWhenThreadExits -- cgit v1.2.3 From 9c0ac8a8febc9d9037991dfebf4eb2f5affd322f Mon Sep 17 00:00:00 2001 From: mcsim Date: Sun, 6 Nov 2011 13:28:37 +0100 Subject: --- user/Maksym_Planeta.mdwn | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 user/Maksym_Planeta.mdwn diff --git a/user/Maksym_Planeta.mdwn b/user/Maksym_Planeta.mdwn new file mode 100644 index 00000000..64dc6e19 --- /dev/null +++ b/user/Maksym_Planeta.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!toc]] +Notes on tmpfs +============== + +#Debugging + +To debug tmpfs, using libraries from "$PWD"/lib and trace rpc: + +settrans -ca foo /usr/bin/env LD_LIBRARY_PATH="$PWD"/lib utils/rpctrace -I /usr/share/msgids/ tmpfs/tmpfs 1M -- cgit v1.2.3