diff options
Diffstat (limited to 'open_issues')
| -rw-r--r-- | open_issues/dde.mdwn | 23 | ||||
| -rw-r--r-- | open_issues/dde/137784 | 43 | ||||
| -rw-r--r-- | open_issues/libpthread_pthread_key_create_reuse.mdwn | 82 | ||||
| -rw-r--r-- | open_issues/libpthread_pthread_key_create_reuse/pthread_key_create_reuse.c | 48 | ||||
| -rw-r--r-- | open_issues/performance/io_system/binutils_ld_64ksec.mdwn | 23 | ||||
| -rw-r--r-- | open_issues/xen_lseek.mdwn | 22 | ||||
| -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 |
8 files changed, 28 insertions, 213 deletions
diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn index 9e2ec742..e2cff94f 100644 --- a/open_issues/dde.mdwn +++ b/open_issues/dde.mdwn @@ -8,25 +8,8 @@ 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]]."]]"""]] -[[General Information|/dde]]. - - -# IRC, freenode, #hurd, 2011-10-18 +[[!tag open_issue_hurd open_issue_gnumach]] -[[!tag open_issue_hurd]] - - [DDE crash, or similar] - <youpi> it's fake_local_irq_disable_flags(), then raw_local_irq_disable(), - then raw_local_irq_restore(), which *does not* release the cli_lock - <youpi> the "prove it" comment is (as I expected) completely wrong - <youpi> npnth: http://paste.debian.net/137784/ - -[[137784]] +[[General Information|/dde]]. - <youpi> could you try this patch ? - <youpi> (I've not even tried to build it) - <npnth> youpi: speaking of which, it still seems to hang :/ I'll 1) double - check it applied correctly and 2) get a gdb output if it did - <youpi> npnth: could you add printing the value of unlock_refcnt? - <youpi> so we can check what's happening - <npnth> unlock_refcnt is at 0, interesting +Still waiting for interface finalization and proper integration. diff --git a/open_issues/dde/137784 b/open_issues/dde/137784 deleted file mode 100644 index 1529465b..00000000 --- a/open_issues/dde/137784 +++ /dev/null @@ -1,43 +0,0 @@ -diff --git a/libdde_linux26/lib/src/arch/l4/cli_sti.c b/libdde_linux26/lib/src/arch/l4/cli_sti.c -index 051f259..6a8c460 100644 ---- a/libdde_linux26/lib/src/arch/l4/cli_sti.c -+++ b/libdde_linux26/lib/src/arch/l4/cli_sti.c -@@ -4,6 +4,8 @@ - - /* IRQ lock reference counter */ - static atomic_t _refcnt = ATOMIC_INIT(0); -+/* Refcnt value at which unlocking the cli_lock (it's not always 0) */ -+static int unlock_refcnt; - static ddekit_lock_t cli_lock; - - /* Check whether IRQs are currently disabled. -@@ -57,9 +59,6 @@ void fake_local_irq_restore(unsigned long flags) - /* Store the current flags state. - * - * This is done by returning the current refcnt. -- * -- * XXX: Up to now, flags was always 0 at this point and -- * I assume that this is always the case. Prove? - */ - unsigned long __raw_local_save_flags(void) - { -@@ -82,7 +81,7 @@ void raw_local_irq_restore(unsigned long flags) - { - Assert(cli_lock != NULL); - atomic_set(&_refcnt, flags); -- if (flags == 0) -+ if (flags == unlock_refcnt) - ddekit_lock_unlock(&cli_lock); - } - -@@ -95,7 +94,9 @@ void raw_local_irq_disable(void) - if (cli_lock == NULL) - ddekit_lock_init_unlocked(&cli_lock); - -- nested_lock(cli_lock); -+ if (nested_lock(cli_lock)) -+ /* Tell the corresponding restorer to release cli_lock */ -+ unlock_refcnt = atomic_read(&_refcnt); - atomic_inc(&_refcnt); - } - 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 |