summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--contributing/web_pages.mdwn21
-rw-r--r--open_issues/libpthread_pthread_key_create_reuse.mdwn82
-rw-r--r--open_issues/libpthread_pthread_key_create_reuse/pthread_key_create_reuse.c48
-rw-r--r--open_issues/performance/io_system/binutils_ld_64ksec.mdwn23
-rw-r--r--open_issues/xen_lseek.mdwn22
-rw-r--r--open_issues/xen_lseek/test-lseek.c (renamed from open_issues/performance/io_system/test-lseek.c)0
-rw-r--r--open_issues/xen_lseek/test-mach.c (renamed from open_issues/performance/io_system/test-mach.c)0
-rw-r--r--user/Maksym_Planeta.mdwn19
8 files changed, 59 insertions, 156 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 <http://git.savannah.gnu.org/cgit/hurd/web.git>. 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
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 ca2da2f5..00000000
--- a/open_issues/libpthread_pthread_key_create_reuse.mdwn
+++ /dev/null
@@ -1,82 +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: pthread_key_create, reuse"]]
-
-[[!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:
-
- <pinotree> youpi: about the bug with pthread keys (reuse): would be an
- acceptable solution having a mutex for the thread_specifics of each
- thread?
- <youpi> you mean one per thread, one global, or one per key, or ?
- <youpi> what is it supposed to protect?
- <pinotree> the thread_specifics of each thread
- <youpi> pinotree: but against what?
- <pinotree> 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
- <youpi> one of the issue is getting to browse through the whole list of
- threads
- <youpi> the other is concurrency between that, and a thread dying
- <pinotree> there's the __pthread_threads_lock rwlock
- <youpi> it should be enough to keep it locked during the iteration
- <pinotree> but that wouldn't be enough when one thread is destroying a key,
- and another one is doing {get,set}specific() on that key
- <youpi> that's not supposed to happen
- <pinotree> mmm
- <youpi> “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.”
- <youpi> undefined -> you are allowed to just blow up
- <pinotree> but it's not been deleted yet... :)
- <youpi> it could be, just a matter of time
- <youpi> you're not supposed to rely on time-luckyness :)
- <pinotree> mmm
- <pinotree> 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 <pthread.h>
-#include <stdio.h>
-#include <assert.h>
-
-#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;
-}
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:
-
- <youpi> hum, f951 does myriads of 71->io_seek_request (32768 0) = 0 32768
- <youpi> no wonder it's slow
- <youpi> unfortunately that's also what it does on linux, the system call is
- just less costly
- <youpi> apparently gfortran calls io_seek for, like, every token of the
- sourced file
- <youpi> (fgetpos actually, but that's the same)
- <youpi> 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/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:
+
+ <youpi> hum, f951 does myriads of 71->io_seek_request (32768 0) = 0 32768
+ <youpi> no wonder it's slow
+ <youpi> unfortunately that's also what it does on linux, the system call is
+ just less costly
+ <youpi> apparently gfortran calls io_seek for, like, every token of the
+ sourced file
+ <youpi> (fgetpos actually, but that's the same)
+ <youpi> and it is indeed about 10 times slower under Xen for some reason
+
IRC, freenode, #hurd, 2011-11-02:
<youpi> 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:
+
+ <youpi> [test-mach.c is] mostly as a reference for the trap overhead
+ <youpi> 0.56µs (xen) vs 0.48µs(kvm) on test-mach
+ <youpi> 455µs(xen) vs 16µs(kvm) on test-lseek
+ <youpi> that might simply be an issue in the RPC mechanism, which behaves
+ badly with the xen memory management
+ <youpi> yes, about 0.5ms for an lseek, that's quite high :)
diff --git a/open_issues/performance/io_system/test-lseek.c b/open_issues/xen_lseek/test-lseek.c
index 667dce66..667dce66 100644
--- a/open_issues/performance/io_system/test-lseek.c
+++ b/open_issues/xen_lseek/test-lseek.c
diff --git a/open_issues/performance/io_system/test-mach.c b/open_issues/xen_lseek/test-mach.c
index 90337346..90337346 100644
--- a/open_issues/performance/io_system/test-mach.c
+++ b/open_issues/xen_lseek/test-mach.c
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