Discuss

discuss@lists.centos.org

5 participants
34752 discussions

Re: [CentOS] [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 29 Jun '05

29 Jun '05

From: alex(a)milivojevic.org > Well, this is how I interpreted Bryan's emails. He'll probably correct me if > I'm wrong (yeah, I have EE, but haven't done much EE work since I > graduated, it just happened to be mostly "software" things for me, so I'm > rather rusty here :-( If you haven't noticed, I am _not_ big on "credentials." As far as I'm concerned, as long as someone has the knowledge, I could care less about the paper**. Even most state BoPEs will allow you to replace an ABET Accredited BSE with 8-12 years of experience (plus another 4-5 years experience post-degree) to qualify to become a PE. There are semiconductor engineering mindsets and they create differ from programmer or even technologist. [ **NOTE: Being a consultant, I finally had to "give in" to the paper. I also decided to major in engineering "just in case I needed it" (and, later on, got to use it for 2 years in the semiconductor industry). ] > I don't think Bryan is talking about "external" width of the address bus, > how many lines you see printed on the motherboard. That's because it is _irrelevant_ in many cases. You can mux lines, which is exactly what the original EV6 Crossbar Athlon does. > He's talking how the things are organized internally, and about the way > the bus logic works. That would be what theoretically implementations > might use, not what some specific implementation is limiting itself to. Exactly. Until the new 40-bit Xeon MPs came out, they were pretty much "slap on" designs with extended ALUs and microcoding to be x86-64 compatible to a point. > Sorry for mixing software and hardware from now on, It hard not to. First you have to consider the programmer aspects. Then you have to realize those will influence hardware compatibility. Then you have to remember that with every new addressing model, you _exponentially_ increase the external logic to drive it. > just trying to make Peter see where his misconception is (the best > way I can, which might not be good way at all). It's fairly difficult to do it without breakout a basic memory controller circuit at least the transistor level, or possibly the combinational NAND gates it somewhat represents. > The programming model for 32-bit userland applications is obviusly > limited to 32 bits -- the sizeof(void *) will tell you that. So single > process can see only 32-bit logical linear address space. To a point. PAE36 is what allows you to break that, because even in the i386, the 16-bit segment register that is offset 4-bits from the 32-bit offset register results in a 36-bit "normalized" address (it can actually be 37-bit, but that's another story). How the processor handles that in a way that is compatible with the OS is the problem. PAE36 uses "paging" from above 32-bit (up to 36-bit/64GiB) down to below 32-bit (upto 4GiB). PAE36 processors can support this paging, and then have at least 36-bit traces on the platform. GTL+ logic was designed with this "slapped on," and never bothered with direct, linear access until just recently (with the new 40-bit redesign for Xeon MP). Athlon, on the other hand, has always been 40-bit EV6. AMD decided to support the PAE36 paging, which added logic. But they _always_ had the "40-bit linear addressing for free" inherently in the platform. That's where these few BIOS hacks come in, combined with an OS/model that can take advantage of it. If you enable this mode for Windows, it will _not_ work! > On the other hand, processor (the hardware) doesn't need to have > such limits, if it's internal organization is wider. So, AMD (processor) > is able to see 40-bit linear physical address space as one single big > chunk of memory. 32-bit applications will have their > 32-bit *logical* address space mapped into this 40-bit linear *physical* > address space of processor. I don't know if programming model of > "32-bit" AMD processors allows you to have wider-then-32-bit pointers > (even if it did, you would have to have compiler that can generate such > code, gcc can't do it for sure). Not true. The model is _still_ PAE36, up to 36-bit/64GiB. But instead of paging, the combination of Athlon's "inherent 40-bit" with an OS that can do it will not use paging. Normally PAE36 does paging, which is what PAE36 OSes normally do. > Obviously, the kernel needs to know how to manage things in this > wider physical address space, the reason why you need patched Linux > kernel to take advantage of it. The actual amount of space doesn't change -- at least not under the PAE36 model. It's just how the OS commands the memory logic to use it, and that also requires the firmware (BIOS) to pre-configure it at POST. Under a norminal PAE36 OS and board, the memory logic and OS always do paging to access above 32-bit/4GiB. But I don't think this hack is able to linearly address the entire 40-bit because of the limitations of what PAE36 can address. > Intel (the processor) on the other hand, is able to physically address > only 32-bit address space. Anything wider than that, it needs to page. > Dealing with paging will obviosly be additional work for OS, hence > lower performance. Paging is a significant hit. Anyone running in the 4G+4G "HIGHMEM" model of their Linux kernel and recompiles for 1G+3G model will notice a noticeable performance gain (as long with only 960MiB of memory). > So while both processors will have more that 32 address lines on the > packaging (and printed on motherboard) minus couple of lowest one > that are not needed) as you can see in various specifications that you > queted, that doesn't mean processor's core actually sees all that > address space. > How else to try explaining this... Hm... Remeber Intel 8086? It could > address only 16-bit address space, but it had more than 16 address lines > on the packaging. It used segmenting (hopefully the right term) to see > wider-than-16-bit address space. Now try to make analogy with what was > discussed so far ;-) It's somewhat correct, although it gets interesting. It's more like EMS than XMS, because XMS used to shunt the processor in and out of Protected286/386, and that required a 286/386 to access it. You could run a true 24-bit/32-bit, respectively, to avoid that. EMS worked on old 8088/8086 (as well as 80286/386), because pages above 1MB could be mapped in. The 80386 and some 80286 could emulate this as well without a special card with special addressing. In the GTL+ bus, this is exactly what it does. It offers special addressing lines for a memory logic that pages, because that's all the OS does. Even the early EM64T processors had to deal with this "limitation" of GTL+ platform. You want to ensure you get a new EM64T platform that doesn't have that approach. -- Bryan J. Smith mailto:b.j.smith@ieee.org

4 3

Re: [CentOS] [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 29 Jun '05

29 Jun '05

From: Peter Arremann <loony(a)loonybin.org> > And that's exactly the part I don't get - if you have a 32bit address model > then you have to use PAE of some sort (compatible to Intel PAE36 or not) to > get to address more than that memory... The BIOS hack basically says "don't be stupid" >4GB. It tells the Athlon MP to the PAE36 addresses linearlly, instead of paging in GTL compatible fashion. With that said, do you mean _beyond_ 36-bit/64GiB? First off, I don't think there ever was an Athlon MP mainboard with more than 64GiB (or more than 32GiB for that matter). Secondly, programs are written to PAE36, so they can only address 64GiB (if not 32-bit/4GiB). *BUT* is it possible for the Athlon MP to still address more than 64GB and "window" (not page) PAE36/64GiB programs? That's a good question, and it's the #1 reason I'm trying to find that post in the LKML. In reality, if the hack uses Linux/x86-64, it could very well be that it puts the Athlon MP in "48-bit/256TiB Long Mode" and translates addreses linearlly. The Athlon MP wouldn't offer PAE52, no. But it _could_ offer PAE36 windows in a 48-bit (40-bit physical EV6) space. Remember, the Athlon/MP and Athlon64/Opteron are the _exact_same_ core design, including the 40-bit/1TiB EV6 interconnect for addressing outside the chip (even if the latter tunnels over HyperTransport between CPUs and I/O to other memory, instead of using a "crossbar switch"). > again - how do I generate a >32bit address when using a 32bit > address model without pages? :-) Remember, in i386 (and, subsequently, the i486 TLB), the segment register is offset at bit 20. That means the most significant bit (MSB) of the segment register actually has a value of 2^35 (32GiB)! Segment: 1111 1111 1111 1111 ____ ____ ____ ____ ____ Offset: ____ 1111 1111 1111 1111 1111 1111 1111 1111 Before PAE36 in the i686, Intel would thrown an exception if you set _any_ of the top 4-bits of the segment register, or if the 5th MSB of the segment was set and either the MSB of the offset, or the previous bits "overflowed" when "normalized" into the physical address. That would result in a physical address >32-bit/>4GiB. In i686 with PAE36, Intel now uses those >32-bit/>4GiB addresses as "pages" into <32-bit/<4GiB addresses. In EV6 with the incompatible "BIOS hack" and a supporting kernel, the Athlon MP's TLB doesn't page, it allows _direct_, _linear_ access above 32-bit/4GiB. Digital EV6 is capable of physically addresssing 40-bit. Intel GTL is only capable of 32-bit. When Athlon is in GTL compatibility mode, it only does 32-bit for full compatibility. But you can tell it to use native, 40-bit EV6 with this BIOS hack. The BIOS hack sets up the crossbar registers which the OS must then support. I'll confirm how this is being done. I believe it actually leverages the Linux/x86-64 kernel. > Once I have that address, throwing it out on the bus is > easy - but how do you generate that address without a PAE? That's where the hack comes in. Remember, _all_ kernels in _all_ OSes use the TLB, hence why an i486 ISA compatible is virtually required these days (or they do it in the kernel's software). Normally the Athlon TLB will do the same thing as any Intel GTL, so any such i686 kernel with PAE36 will normally do the same thing. But the BIOS hack puts the Athlon TLB into its _true_ 40-bit EV6 addressing, and the kernel then knows of this and uses it. > So you're simply talking about being the ability to output an > address longer than 32bit on the bus? It's more than just that. It's the combination of presenting PAE36 to _user_ software, while using _linear_ addressing physically. Intel i686+GTL already does PAE36, and pages in addressings above 32-bit. Athlon+EV6 normally just emulates that, right down to the TLB. This hack doesn't, it unleashes the Athlon as it's meant to work on a 40-bit interconnect designed for 64-bit Alpha processors. And that includes having the kernel drive the TLB to just take those >32-bit "normalized" addresses that would normally be "paged" and just act like it's linear space. As far as above 36-bit, I'm not sure. I'll check on that. > on AMD64, yes, thats for sure... but you were referring to > 32bit athlons in the statement I'm trying to understand. And what I'm saying is that Athlon is Athlon. It's the same core, same 40-bit EV6 interconnect. Everything else is compatibility. On Athlon 64, you can run a PAE52 kernel (on its 40-bit physical platform) and run PAE36 applications, giving linear address space to them all while they think paging is being used. What this hack does is do the same thing for Athlon MP -- marketed as "32-bit," but the _same_ 40-bit capable, _physical_ platform. EV6 is EV6, designed for 64-bit Alpha, and AMD couldn't "cripple" it. They use the same board logic and cores, whether a 32-bit Athlon or 64-bit Alpha are used. But doing anything but traditional, GTL 32-bit/PAE36 would normally _break_ hardware and OSes. Unless you have a hack to the BIOS which enables this "Linux" memory mode, and a kernel which supports it. Again, I'll find the post, which will lead me to the tech info. -- Bryan J. Smith mailto:b.j.smith@ieee.org

6 17

Re: [CentOS] Directory Server for CentOS 4.1
by Bryan J. Smith <b.j.smith＠ieee.org> 28 Jun '05

28 Jun '05

From: Johnny Hughes <mailing-lists(a)hughesjr.com> > The plan for Directory Server for CentOS-4 is to port RedHat Directory > Server (and not Fedora Directory Server) when it is released for RHEL. > That should happen when RedHat thinks it is stable for production in the > enterprise ... I would assume that they will charge for it like they do > for RHGFS/RHCS when they feel they have it stable. I thought that have been doing that since the AOL deal last year? It had been available on the RHN for awhile, in the unchanged/original form. Unless I was mistaken, the deal was that AOL would allow Red Hat to GPL it after an undisclosed number of sales had occurred _or_ by April 30, 2005, whichever came first. The new FDS and RHDS releases are just more updated/integrated releases with the Red Hat product line. E.g., more integrated SASL/Kerberos integration with Red Hat's offerings out-of-the-box. Previously there was a lot of post-install work to get Kerberos working via GSSAPI. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

[OT] CentOS web form troubles
by Paul Heinlein 28 Jun '05

28 Jun '05

It looks as if the "Contact Us" form for sending comments to the CentOS webmasters (http://www.centos.org/modules/contact/) is trying to send mail to donavan(a)mail.centos.org, which apparently gets forward to an account @4wx.net. The mail server for that domain is having a hard time communicating with mail.centos.org. Is there anyone on this list who can confirm, deny, or report the problem? :-) -- Paul Heinlein <> heinlein(a)madboa.com <> www.madboa.com

1 0

Re: [CentOS] U320 PCI-X SCSI HBA experiences on x86_64
by Bryan J. Smith <b.j.smith＠ieee.org> 28 Jun '05

28 Jun '05

From: Alan Hodgson <ahodgson(a)simkin.ca> > Does anyone have any good or bad driver/performance/stability > experiences with either: > LSI Logic LSIU320 > Adaptec 29320ALP-R or (or other current boards using the same driver) > in Opteron servers running RHEL 4 or CentOS 4, x86_64? > Thanks in advance. I can't remember if I brought it up on this list, but my permanent home is less than 5 miles from Adaptec's major support center in Orlando. I know several gentlemen who have worked their throughout the years, and many of them have told me the same thing. If you use Adaptec, use the _retail_ products. The OEM editions have custom firmware and changes, and the Linux drivers are often not guaranteed to work. Indeed I have regularly run into numerous issues with many Adaptec products that have come with servers, even a few of the tier-1 OEMs who ship and support Linux for servers (this is less commonplace in more recent years). As such, I have always preferred Symbios Logic / LSI Logic products because the overwhelming majority of their products are the same -- either retail or whitebox OEM. I've yet to have an issue with the former Symbios Logic 53c8xx/1xxx products or LSI solutions under Linux. If you have an OEM or integrator providing you solutions, especially if you have a SLA with them, then by all means, use what they will support. Otherwise I tend to prefer Symbios/LSI products. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Directory Server for CentOS 4.1
by User Lists 28 Jun '05

28 Jun '05

Hi all, Somebody has tested directory server (http://directory.fedora.redhat.com/wiki/Main_Page) under CentOS 4.1?? Is it ready for production environments?? Somebody has ported to centos?? Thank you very much. __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/

5 4

U320 PCI-X SCSI HBA experiences on x86_64
by Alan Hodgson 28 Jun '05

28 Jun '05

Does anyone have any good or bad driver/performance/stability experiences with either: LSI Logic LSIU320 Adaptec 29320ALP-R or (or other current boards using the same driver) in Opteron servers running RHEL 4 or CentOS 4, x86_64? Thanks in advance. -- Inside every older person is a younger person wondering what happened

1 0

Web Proxy/Monitoring Software?
by Scott Sharkey 28 Jun '05

28 Jun '05

Hi All, I have a need for a service or software that will monitor and track outbound HTTP (web) accesses, and report what pages are being visited. I know that Squid theoretically can do this, but it seems like overkill for this application. The user could care less about caching - they just want to monitor what URL's their staff is visiting. IS squid the best option, or is there something else that would do a better job? Part of my concern is that the machine they have to run this on does not have a huge amount of memory, and I understand Squid can be a memory hog. Thanks!!! -Scott

2 1

Re: [CentOS] Re: Directory Server for CentOS 4.1
by Bryan J. Smith <b.j.smith＠ieee.org> 28 Jun '05

28 Jun '05

From: Avtar Gill <avtargill(a)gmail.com> > I can't comment about that directory server but I have been using Novell > eDirectory on CentOS 3.* without any problems. Considering that it's > utilized in numerous universities and government organizations around > the world, I would say it's definitely production grade software. Just know that I've seen NsDS deployed in 10,000+ node networks going back to the late '90s. I don't think people realize what deal the community has gotten thanx to yet another Red Hat purchase released, as always, 100% GPL. OpenLDAP wasn't cutting it IMHO, and Red Hat refuses to offer solutions that aren't GPL. Hence why they came to an arrangement with AOL to see NsDS GPL'd after they "gave up" on OpenLDAP. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Directory Server for CentOS 4.1
by Bryan J. Smith <b.j.smith＠ieee.org> 28 Jun '05

28 Jun '05

From: User Lists <clopmz(a)yahoo.com> > Hi all, > Somebody has tested directory server > (http://directory.fedora.redhat.com/wiki/Main_Page) > under CentOS 4.1?? Is it ready for production > environments?? Somebody has ported to centos?? You _do_ understand it's basically Netscape Directory Server, correct? NsDS has been more "production ready" than OpenLDAP ever has IMHO. And yes, it runs on even non-Linux platforms (e.g., Solaris), so I'd say it runs on just about any Linux platform. Integration considerations might be another, more involved detail though. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss