diff options
| -rw-r--r-- | hurd/running/qemu/discussion.mdwn | 92 | ||||
| -rw-r--r-- | microkernel/mach/gnumach/ports/xen.mdwn | 24 | ||||
| -rw-r--r-- | toolchain.mdwn | 8 | ||||
| -rw-r--r-- | toolchain/elfosabi_hurd.mdwn | 83 | ||||
| -rw-r--r-- | user/jkoenig/java.mdwn | 5 |
5 files changed, 204 insertions, 8 deletions
diff --git a/hurd/running/qemu/discussion.mdwn b/hurd/running/qemu/discussion.mdwn index fd0df4c5..1ce14b01 100644 --- a/hurd/running/qemu/discussion.mdwn +++ b/hurd/running/qemu/discussion.mdwn @@ -50,3 +50,95 @@ The problem is actually that the linux block cache doesn't make any consistency between /dev/hda and /dev/hda6, so if you give /dev/hda to qemu, qemu writings won't be consistent with mounting /dev/hda6 in linux. You can give /dev/hda6 directly to qemu and it will be fine. + + +# Host-side Writeback Caching + +IRC, freenode, #hurd, 2011-06-07 + + <braunr> hm, i guess i should have used cache=writeback with kvm before + starting the debian installer :/ + <braunr> ah yes, much better + <braunr> this shows how poor the state of our I/O drivers and subsystem is + :/ + <antrik> indeed... still no clustered pageout :-( + <braunr> and no I/O scheduler either + <braunr> although an I/O scheduler has limited value without clustered + pageouts + <braunr> since one of its goals is to pack related I/O requests together eh + <braunr> i wonder if the wiki mentions using cache=writeback to speed up + qemu performances + <braunr> it would help those unable to use kvm a lot + <braunr> and even those running kvm too + <braunr> kvm -m $RAM \ -monitor stdio \ -drive + cache=writeback,index=0,media=disk,file=hd0.img \ + <braunr> etc.. + <braunr> the idea is that qemu doesn't open its disk file synchronously + <braunr> changes are queued in the host page cache before being flushed to + the disk image + <braunr> but if you brutally close your qemu instance, you're likely to + loose file system consistency + <braunr> ext2fs will think it has committed its metadata to the disk, but + the disk image won't be updated synchronously + <braunr> on my machine (which is quite fast), my kvm has installed debian + like 10 times faster than without the option + <antrik> braunr: I don't think killing qemu should hurt in this + case... probably only matters when the host machine dies + <braunr> antrik: ah yes, right + <braunr> it really makes everything faster, even downloading, since I/O + requests aren't interleaved between networking RPCs + <antrik> regarding I/O sheduler... this discussion came up before, but I + don't remember the outcome -- doesn't the glued Linux driver actually + come with one? + <braunr> i don't remember either + <antrik> braunr: err... I don't think interleaving has anything to do with + it... I guess it's simply the fact that downloading writes the result to + disk, which suffers from lacking clustered pageout like everything else + <antrik> (my internet connection is too slow though to notice :-) ) + <braunr> well, if there is no I/O during downloading, downloading is faster + :) + +IRC, freenode, #hurd, 2011-06-08 + + <braunr> youpi: does xen provide disk caching options ? + <youpi> through a blktap, probably + <braunr> ok + +([[microkernel/mach/gnumach/ports/Xen]], *Host-side Writeback Caching*.) + + <braunr> we should find the pages mentioning qemu on the wiki and add the + options to enable disk image caching + <braunr> it really makes the hurd run a lot faster + <braunr> as a workaround for emulators until I/O is reworked, ofc + +IRC, freenode, #hurd, 2011-06-09 + + <gnu_srs> braunr recommends to use writeback caching with kvm. Is this + really recommended with the frequent crashes I experience? + <youpi> provided that you terminate your kvm normaly (i.e. quitting it, not + killing it), there should be no difference + <jkoenig> I think the host's stability is what matters + <jkoenig> the data presumably sits in linux's cache even if qemu dies + violently + <gnu_srs> But the freezes I see force me to kill kvm :-( + <youpi> maybe kvm doesn't even do caching indeed, I don't know + <youpi> gnu_srs: you can quit even when frozen + <youpi> use the console + <youpi> (the kvm console) + <jkoenig> gnu_srs, "Writeback caching will report data writes as completed + as soon as the data is present in the host page cache. This is safe as + long as you trust your host. If your host crashes or loses power, then + the guest may experience data corruption." (from the qemu manpage) + +IRC, freenode, #hurd, 2011-06-11 + + <gnu_srs> braunr: If you are online. For me setting the parameters -drive + cache=writeback,index=0,media=disk,file=hd0.img does not show any speed + improvement at all compared to the default. + <braunr> gnu_srs: what's your complete qemu command line ? + <gnu_srs> kvm -m 1024 -net nic,model=rtl8139 -net + user,hostfwd=tcp::5556-:22 -drive + cache=writeback,index=0,media=disk,file=hd0.img -cdrom netinst.iso + <braunr> what qemu version ? + <gnu_srs> qemu-kvm 0.14.1+dfsg-1: Sorry, I cannot be online until + tomorrow again. diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn index bf26410a..af431c92 100644 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ b/microkernel/mach/gnumach/ports/xen.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,11 +6,12 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!toc]] + # Xen dom0, hypervisor /!\ Now that GNU Mach handles PAE you can use a PAE-enabled hypervisor. @@ -30,6 +31,7 @@ If you have a free partition, you can fdisk to type 0x83, create a filesystem us Replace /dev/sda4 with your partition. Install and use crosshurd to setup a GNU/Hurd system on this partition. + # /etc/xen/hurd configuration Here is a sample /etc/xen/hurd configuration @@ -49,6 +51,7 @@ Suggestions about [[networking_configuration]] are available. If you need stable MAC addresses, use a syntax like `vif = [ 'mac=00:16:3e:XX:XX:XX, bridge=br0' ]`. + # Running Hurd with Xen To run Hurd with Xen, use: @@ -63,6 +66,7 @@ and gnumach should get started. Proceed with native-install. - If `xm` complains about networking (`vif could not be connected`), it's Xen scripts' fault, see Xen documentation for how to configure the network. The simplest way is network-bridge with fixed IPs (note that you need the bridge-utils package for this). You can also just disable networking by commenting the vif line in the config. - If `xm` complains `Error: (2, 'Invalid kernel', 'xc_dom_compat_check: guest type xen-3.0-x86_32 not supported by xen kernel, sorry\n')`, you most probably have a PAE-enabled hypervisor and a non-PAE gnumach. Either install and boot non-PAE hypervisor and kernel, or rebuilt gnumach in PAE mode. + # Building from sources If you want to generate these images, first get the `gnumach-1-branch-Xen-branch` branch from gnumach CVS. @@ -75,7 +79,6 @@ Then use The current `hurd-modules` was built from the debian packages `hurd 20070606-2` and `libc0.3 2.6.1-1`. /!\ This means that when using this image, your GNU/Hurd system also needs to be a glibc version 2.6 or later-based one! ---- # Miscellaneous @@ -83,7 +86,6 @@ The current `hurd-modules` was built from the debian packages `hurd 20070606-2` [[!GNU_Savannah_task 5468]], [[!GNU_Savannah_task 6584]]. ---- # `pv-grub` @@ -91,3 +93,15 @@ From Xen 4.0 on you'll be able to run the GNU Hurd directly using `pv-grub`, without the need to [prepare a special bootstrap image](http://youpibouh.thefreecat.org/hurd-xen/build_hurd-modules) (like an initrd). + + +# Host-side Writeback Caching + +Optimization possible as it is with [[QEMU|hurd/running/qemu/discussion]], +*Host-side Writeback Caching*? + +IRC, freenode, #hurd, 2011-06-08 + + <braunr> youpi: does xen provide disk caching options ? + <youpi> through a blktap, probably + <braunr> ok diff --git a/toolchain.mdwn b/toolchain.mdwn index b08dba95..0059317b 100644 --- a/toolchain.mdwn +++ b/toolchain.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -24,4 +24,10 @@ for example, how things are done differently for GNU/Hurd than they are done for GNU/Linux. +--- + + * [[ELFOSABI_HURD]] + +--- + * [[cross-gnu]] diff --git a/toolchain/elfosabi_hurd.mdwn b/toolchain/elfosabi_hurd.mdwn new file mode 100644 index 00000000..4d60f761 --- /dev/null +++ b/toolchain/elfosabi_hurd.mdwn @@ -0,0 +1,83 @@ +[[!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="ELFOSABI_HURD"]] + +[[!tag open_issue_binutils open_issue_glibc]] + + +# [[!debbug 630180]] + + +# [[open_issues/binutils]] commit 51b2f560ad035dffad3371093f8e5c80608d196c + +Usage of `ELFOSABI_LINUX`/`STB_GNU_UNIQUE`. Has also been wrong before already +with respect to `STT_GNU_IFUNC`? + + +# IRC + +IRC, freenode, #debian-hurd, 2011-06-11 + + <pinotree> youpi: not that there would be any hope in that, but id you try + asking doko about the gcc miscompiling (wrong elf format) issue? + <youpi> I didn't + <youpi> I'm still investigating + <youpi> maybe it's a binutils change actually + <pinotree> youpi: hm, are you sure it could be binutils? after all, even + some .o files are produced with format gnu/linux, so there's no binutils + involved up to that point of thecompilation yet? + <youpi> as is + <youpi> "as", I mean + <pinotree> i see + <youpi> since it's so unclear, I really prefer to investigate before + bothering doko + <pinotree> youpi: maybe i could be wrong, + <pinotree> in binutils, bfd/elf.c, around lines 9580 + <youpi> the faulty thing seems to be gnu_unique_object in the source .s + file produced by g++ + <pinotree> that's what that comment (which changed wrt binutils from eg + march) says + <youpi> seems to concur with my comment above :) + <pinotree> http://paste.debian.net/119542/ ¡û extract of diff + <youpi> ok, that really seems the culprit + <youpi> starting reportbug + <pinotree> who's the fault then? + <youpi> binutils + <youpi> it shouldn't hardcode LINUX + <pinotree> g++ emitting those symbols, or binutil considering them "linux"? + <youpi> it's a GNU thing, not a Linux thing + <pinotree> ah ok + <youpi> it's the same dynamic linker actually + <pinotree> youpi: http://sourceware.org/bugzilla/show_bug.cgi?id=10549 + <pinotree> see the reporter :) + <youpi> heh + <pinotree> youpi: see also gas/config/obj-elf.c:1725 + <pinotree> (another change related to that bug, it seems) + +IRC, freenode, #hurd, 2011-06-15 + + <jkoenig> also I still get an "ELF file OS ABI invalid" error with binutils + 2.21.52.20110606-2+hurd.1, is that expected? + <youpi> tschwinge: oops, the OS ABI invalid is actually due to the file + being marked GNU/Hurd + <youpi> I guess the linker is simply not aware that it should accept + GNU/Hurd + <tschwinge> youpi: So we got to work on glibc'S ld.so to teach it aboput + the Hurd OS ABI? (Or probably simply make that equivalent to the Linux + one?) + <youpi> probably simply an equivalent + <youpi> ELFOSABI_HURD is missing from elf/elf.h, for a start... + <youpi> linux' glibc has tests in lsdodefs.h + <youpi> the VALID_ELF_OSABI macro + <youpi> it's thus apparently a matter of providing an ldsodefs.h file with + VALID_ELF_HEADER, VALID_ELF_OSABI and VALID_ELF_ABIVERSION definitions + <youpi> (and include_next the generic one) + <youpi> I've prepared a patch for ldsodefs.h, I'll test it diff --git a/user/jkoenig/java.mdwn b/user/jkoenig/java.mdwn index 6aeef9fe..8e1fb097 100644 --- a/user/jkoenig/java.mdwn +++ b/user/jkoenig/java.mdwn @@ -140,7 +140,7 @@ by building on [[pochu]]'s `file_exec_file_name()` I have succeeded in building a Hotspot-enabled `libjvm.so`, although the current toolchain issues -(*Hurd OS ABI*) +([[toolchain/ELFOSABI_HURD]]) have so far prevented me from testing it. @@ -151,7 +151,8 @@ have so far prevented me from testing it. * Assuming it is, continue with getting `$ORIGIN` working. - * [!] [[Samuel|samuelthibault]]/[[tschwinge]]/[[jkoenig]]: *Hurd OS ABI*. + * [!] [[Samuel|samuelthibault]]/[[tschwinge]]/[[jkoenig]]: + [[toolchain/ELFOSABI_HURD]]. * They seem to have a rather heavy-weight process for such projects: confer <http://mail.openjdk.java.net/pipermail/announce/2011-January/000092.html>, |