Re: About Xen: maybe a reiterative question but ..
On Tuesday 23 October 2007 18:22:00 ropers wrote:
Hi Christoph,
Right now, on the OpenBSD misc mailing list, there is this discussion:
http://www.sigmasoft.com/~openbsd/archives/html/openbsd-misc/2007-10/thread
s.html#01149 about OpenBSD/Xen.
We last spoke last year, when I put your BSDtalk interview transcript
online at http://ropersonline.com/openbsd/xen .
It seems to me that most people on the misc mailing list currently are
not very aware of your OpenBSD Xen port. Could I possibly ask you to
participate in the discussion? I feel that you (and Theo) are the only
guys who can provide authoritative answers on the issue.
Some of the questions that I feel are unclear are:
- Was your porting work fully completed? IIRC it was, but please clarify.
DomU support is ready. Dom0 is work in progress.
(apart from use-after-free bugs in MI buffer-cache and filesystem code,
which damages filesystem.)
Dom0 is work in progress, but is stalling on a NULL-pointer bug
in uvm_pglistalloc_simple().
This code piece in the kernel reproduces this crash:
void foo(void)
{
struct pglist mlist;
uvm_pglistalloc(PAGE_SIZE * 64, 0, 0x, 0, 0, mlist, 64, 0);
}
I didn't investigate further into this, because I have put my focus
on the xen-kernel and xen-tools to compile on OpenBSD and NetBSD
out-of-the-box. To finish this task, I need some things in OpenBSD:
- aio(2) support
- POSIX ptsname() (this is used in a python binding module)
- newer gcc version due to a structure padding bug with
an alignment attribute hidden in a typedef (this is fixed in gcc 3.4)
I use gcc 4.2 from the ports FYI.
- I need i386 headers and libc on OpenBSD/amd64 for 64bit builds.
gcc -m32 defines __i386__ so it is possible to distinguish if a
#include stdint.h must provide 32bit or 64bit integer type definitions.
Oh, a libc header cleanup is nice to have. I don't know why uvm kernel headers
should be in /usr/include/uvm/, for example.
- Is your port still being maintained? Can it be run with OpenBSD
-current or 4.2?
4.1. It needs an update. Maybe some of the nasty MI bugs are gone.
- It seems to me that your port didn't achieve wide recognition and
acclaim because of a lack of publicity.
I'm not a marketing guy.
- AFAIK your OpenBSD/Xen port code hasn't found its way into the
official OpenBSD distribution. Is this correct?
yes.
- Are there any reasons why your code didn't go into the official
OpenBSD distro? Was it lack of awareness? Have you ever talked to Theo
and/or other central OpenBSD people?
I haven't found someone who is willing to commit the diffs.
- Is there any hope that your port might still become part of the
official OpenBSD distribution?
(Theo: Could you possibly comment as well?)
I don't know.
I'd personally be very interested to see your port become part of the
official distribution, but I sadly can't code myself, so all I can do
is ask and hope. :)
Once again, thanks for your hard work. :)
You're welcome.
Many thanks in advance and kind regards,
Jens Ropers
Re: About Xen: maybe a reiterative question but ..
On Wednesday 24 October 2007 16:14:19 Chris Kuethe wrote: On 10/24/07, carlopmart [EMAIL PROTECTED] wrote: Dear sirs please: I will return to my original question. I just wondered if xen will be included into the OpenBSD's kernel to act as a para-virtualized DomU or not. Nothing more. I will not go into issues of the type is insecure or not. Theo, or somebody from developer team: Will be para-virtualized domU xen kernel included on next OpenBSD release (4.3?) or not?? I only want to know this... Not unless someone actually writes the code to do it. Notice the extreme number of people with openbsd.org email addresses jumping up and down, volunteering to do it (hint: none). Possibly not even if someone writes the code. Diffs are not always merged. They should be good diffs that improve OpenBSD. Notice the number of people with openbsd.org email addresses who are not convinced that doing this a) will improve OpenBSD and b) won't actually hurt. So I'm going to guess the answer is No, integrating xen paravirtualization is not a project priority at this time. Also, where are your diffs? The OpenBSD/Xen source is at http://hg.recoil.org/openbsd-xen-sys.hg Unfortunately, Anil has troubles with the availability of the server. I rely on having a willing OpenBSD developer who commits the patches I send to him. But as long as there is none, it doesn't go in. Christoph
Re: About Xen: maybe a reiterative question but ..
On Wednesday 24 October 2007 17:25:25 Artur Grabowski wrote: Christoph Egger [EMAIL PROTECTED] writes: So I'm going to guess the answer is No, integrating xen paravirtualization is not a project priority at this time. Also, where are your diffs? The OpenBSD/Xen source is at http://hg.recoil.org/openbsd-xen-sys.hg Unfortunately, Anil has troubles with the availability of the server. I rely on having a willing OpenBSD developer who commits the patches I send to him. But as long as there is none, it doesn't go in. I'm willing to stretch as far as saying: This might be interesting for some testing purposes for kernel hackers if Xen could be hosted on OpenBSD. But this doesn't mean that I'm even close to volunteering doing the job. It just would be cool to have if it doesn't break stuff. //art Actually it is good to find NULL-pointer (mostly use-after-free) bugs, that are hard to find on real hardware. Believe me or not: OpenBSD has tons of them. Christoph
Re: Get developers some big machines to support more RAM
On Monday 08 October 2007 12:02:22 mickey wrote: On Mon, Oct 08, 2007 at 11:53:50AM +0200, Tonnerre LOMBARD wrote: Salut, On Mon, Oct 08, 2007 at 09:44:48AM +, mickey wrote: PAE is slow and has hairy paws. I am glad that we have real amd64 machines now so we don't need it anymore. besides that what do you think amd64 runs? (: it uses the same pae as i386. and it is not any faster. learn what are you talking about... No, it uses 48-bit addresses and some flag bits, but it can use a 64-bit selector rather than two 32-bit ones, improving the performance significantly. format and amount of data is the same. it does not matter how many bits are used or not. it's about how much larger page tables are and how much longer it takes for the tlb reload. or what you think loading 36bit physaddr is slower than loading 48bits? segments have nothing to do w/ page tables and tlb performance. they will be as much slowdown on pae or non-pae page tables. get a clue. you are talking about non-related improvements and might as well compare this to sparc64 tlb performance... cu in legacy mode, there is i386 that support 4KB and 4MB page-sizes and use 2-level pagetables. in legacy mode, there is i386 PAE that support 4KB and 2MB page-sizes and use 3-level pagetables. in long mode, there is amd64 that support 4KB, 2MB and 1GB page-sizes and use 4-level pagetables. i386 PAE and amd64 use the same paging-mode. The larger pagetables look like the pagewalk slows down, but actually the MMU internally does some optimizations that allow jumps w/o modifying the pages used for the pagetables. What is a real speedup is support for the large pages (4MB/2MB) and the newly introduced giga-pages (1GB) in Barcelona since they reduce TLB flushes or TLB pressures. Oh, and some off-topic hints that also result in speedups: Fine-graine locking increases speed over the biglock, a better scheduler that prevents jumping from processes between cpu-cores or even better between NUMA-nodes. Christoph
OpenSSH: lost connection
Hi! I trying to transfer a 1.8GB file with this command: scp -c blowfish myfile.bz2 otho:/data/ After some retries, scp keeps failing at 58% with the error msg: myfile.bz2 58% 1023MB 0.0KB/s - stalled - Host key verification failed. lost connection Has anyone an idea, what is going wrong?
Intel Core 2 - round #2
Linus contradicts Theo on Intel TLB issue: http://blogs.zdnet.com/Ou/?p=559 Christoph
Re: Limit filesharing traffic with PF
On 11/4/05, Christoph Egger [EMAIL PROTECTED] wrote: The P2P traffic can be identified this way: - The source IP from one client is always the same - The client establishes lots of connections to many destination IP adresses Use synproxy, max-src-states, and overload tables. Automagically locks out agressive clients such as viruses and P2P users (and people browsing Fark photoshop threads). For bonus points, script the addition of the MAC address to your switching ACLs. This is a great idea. Tnx. But I also want to unlock them automatically after 15 minutes again, except infected clients. Worms can be identified by filtering outgoing port 25, which is no problem. Incoming traffic is locked generally due to nat n:1. -- Jon Simola Systems Administrator ABC Communications -- Greetings, Christoph Highspeed-Freiheit. Bei GMX superg|nstig, z.B. GMX DSL_Cityflat, DSL-Flatrate f|r nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl
Limit filesharing traffic with PF
Hello! I have the following problem: Filesharing users eat the whole available bandwidth and they use lots of connections at the same time. The result is an overloaded gateway. Locking ports doesn't help, because they do port-hopping. My goal: I want to create a queue which limits the bandwidth for P2P protocols to 1MBit/s. Everything else (i.e. WWW, E-Mail, VPN) is outside this queue. The rough solution: Creating the queue is documented in pf.conf(5) manpage very well, so this is not a problem. The P2P traffic can be identified this way: - The source IP from one client is always the same - The client establishes lots of connections to many destination IP adresses Where I need help: I need to create the PF rules in pf.conf which identifies the P2P traffic and tags it. But I don't know how to do that. Redirecting the tagged P2P traffic into a queue is not a problem for me then. Thank you in advance! -- Greetings, Christoph Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen f|r GMX Partner: http://www.gmx.net/de/go/partner
