Re: Get developers some big machines to support more RAM
On Mon, Oct 08, 2007 at 11:23:12AM +0200, Tonnerre LOMBARD wrote: Salut, On Mon, Oct 08, 2007 at 09:14:05AM +, mickey wrote: myself in need to build some big, phat machines (8GByte, or even 16GByte RAM) for a customer that run OpenBSD *and* having seen (again) a discussion on 'how much RAM is supported' [0] I decided to PAE support has already been hacked up. apparently it was backed out for some obscure stability problems on certain amd machines. and this is (as i see it) fault exactly of these people who wants this support since when it was asked for the diff received ZERO testing for large memory use from the list. i will repost it again (w/ weak hope) that somebody bothers to actually test or look at it... PAE is slow and has hairy paws. I am glad that we have real amd64 machines now so we don't need it anymore. you do not need it perhaps. otherwise there has been lots of talkers for it on i386. cu -- paranoic mickey (my employers have changed but, the name has remained)
Re: Get developers some big machines to support more RAM
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. Please also note that PAE only has 36-bit addresses, allowing for up to 64GB of RAM, while AMD64 allows for 256TB, theoretically. Well, s/RAM/address space/ Tonnerre [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Get developers some big machines to support more RAM
On Mon, Oct 08, 2007 at 09:43:25AM +, mickey wrote: On Mon, Oct 08, 2007 at 11:23:12AM +0200, Tonnerre LOMBARD wrote: Salut, On Mon, Oct 08, 2007 at 09:14:05AM +, mickey wrote: myself in need to build some big, phat machines (8GByte, or even 16GByte RAM) for a customer that run OpenBSD *and* having seen (again) a discussion on 'how much RAM is supported' [0] I decided to PAE support has already been hacked up. apparently it was backed out for some obscure stability problems on certain amd machines. and this is (as i see it) fault exactly of these people who wants this support since when it was asked for the diff received ZERO testing for large memory use from the list. i will repost it again (w/ weak hope) that somebody bothers to actually test or look at it... 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... cu -- paranoic mickey (my employers have changed but, the name has remained)
Re: Get developers some big machines to support more RAM
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 -- paranoic mickey (my employers have changed but, the name has remained)
Re: Get developers some big machines to support more RAM
Salut, On Mon, Oct 08, 2007 at 10:02:22AM +, mickey wrote: or what you think loading 36bit physaddr is slower than loading 48bits? I think that loading 48-bits in one step is faster than loading 36-bit in two. It is also a matter of experience that amd64 memory access is way faster than i386 with PAE. i386 is dying out finally, that's what I meant to say. amd64 has been elected as the architecture of the future by most if not all hardware producers. We got rid of one of the worst pieces of hardware ever, at least partially. This is why I suggested that it might be less of an issue to most people. For a good reason: nowadays, you just get an amd64 and don't have the problem. Tonnerre [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Get developers some big machines to support more RAM
You don't get the problem, at least if you run a decent operating system, 'cause I know some people having problem using more than 4 Gig of ram, even with AMD64 or EM64T hardware, and (hum) Vista. Just to say the arch does not make everything, a good software is also needed. plus, X86_64 gets rid of a part of the limitation of the old x86 model, but not everyting... like old bad bios (still waiting for EFI), 640K thing, 8GB, 128/137GB HDD hacks... On 10/8/07, Tonnerre LOMBARD [EMAIL PROTECTED] wrote: Salut, On Mon, Oct 08, 2007 at 10:02:22AM +, mickey wrote: or what you think loading 36bit physaddr is slower than loading 48bits? For a good reason: nowadays, you just get an amd64 and don't have the problem.
Re: Get developers some big machines to support more RAM
Salut, On Mon, Oct 08, 2007 at 11:15:27AM +, mickey wrote: I think that loading 48-bits in one step is faster than loading 36-bit in two. It is also a matter of experience that amd64 memory access is way faster than i386 with PAE. why do you think that tlb loader cannot load 64bits in one step in i386 mode either? I'm talking long mode here. For a good reason: nowadays, you just get an amd64 and don't have the problem. lots of amd64 machines have much of their own stability problems. it is as well a different architecture that requires recompiling software that may or may not be 64bit clean. of course running your favourite irc client would not matter... The software should be migrated, and it is happening. Why BitchX doesn't work on amd64 is not my problem. Also, most software problems can be resolved by compiling the software with something that is not gcc. Tonnerre [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Get developers some big machines to support more RAM
On Mon, Oct 08, 2007 at 12:13:55PM +0200, Tonnerre LOMBARD wrote: Salut, On Mon, Oct 08, 2007 at 10:02:22AM +, mickey wrote: or what you think loading 36bit physaddr is slower than loading 48bits? I think that loading 48-bits in one step is faster than loading 36-bit in two. It is also a matter of experience that amd64 memory access is way faster than i386 with PAE. why do you think that tlb loader cannot load 64bits in one step in i386 mode either? i386 is dying out finally, that's what I meant to say. amd64 has been elected as the architecture of the future by most if not all hardware producers. We got rid of one of the worst pieces of hardware ever, at least partially. This is why I suggested that it might be less of an issue to most people. For a good reason: nowadays, you just get an amd64 and don't have the problem. lots of amd64 machines have much of their own stability problems. it is as well a different architecture that requires recompiling software that may or may not be 64bit clean. of course running your favourite irc client would not matter... cu -- paranoic mickey (my employers have changed but, the name has remained)
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
Re: Get developers some big machines to support more RAM
OK guys, Instead of fighting about using, or not using it, or i386 being obsolete, PAE not being good, or slow, etc. I for one would be very happy if we can support more then 4GB of memory on it and I would be more then happy to test it as I now have machine that actually have more then 4GB in them. If other would test as well, may be instead of talking about it, we could make progress on it. I would be way more then happy to turn over full access to a Sun X4100 M2 fully accessible on the net as well if that help any for a month or two, or more if needed, if any one is interested. I would even load it up with 16GB of memory if that would be useful from the 8GB that is already there. This box is sadly not as stable as it should be anyway and I can't use it in production using the AMD64-MP kernel, so anything that can help it, I can test or turn it over to someone that actually would be interested to play with it. If someone even want to really bag it out, I would even turn over 4 of them if that's any help. Anyway, as of now, if there is something that needs testing, I could do that in the nest of my ability. Anything else is just talk and doesn't help any does make any progress in the right direction either. Thanks. Daniel
Re: Get developers some big machines to support more RAM
Christoph Egger 8-Oct-07 12:54 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. If you've finished lecturing one of the guys that worked on the original amd64 port of OpenBSD, we look forward to seeing your diffs for fine-grained locking etc. Thanks Tom
Re: Get developers some big machines to support more RAM
Timo Schoeler wrote: AMD64 or EM64T machine with 8GB+ of RAM (or $1700 to buy one) needed in Edmonton. Contact [EMAIL PROTECTED] Having the hardware will help some. I've got access to some larger hardware here at the university, and have sent out the large mem diff for amd64 machines. I've had almost ZERO feedback. In the end I've given up for the time being. I'd still love having my own machine with 8GB+ of ram, it may motivate me in actually finishing the patch (for amd64 at least), and possibly help in motivating me testing any future buffer cache diffs... -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
