Discuss

discuss@lists.centos.org

3 participants
34748 discussions

Re: Offtopic Posts [was 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: Chris Mauritz <chrism(a)imntv.com> > I agree completely. Unfortunately, even though I've killfiled the > biggest offender, I'm still getting a lot of the noise since people > continue to feed him. I assume the former is a reference to me. As far as the latter, you might re-think your singularity focus. As I've said before, you can't complain about me without complaining about others too. I.e., I try to point out things with_out_ going down into the tangent. Then people "get smart" with me believing what I say is not true. I can then either "let it go" and then people dismiss my offering of my experience and knowledge. Or I can correct them with the tangent. It's a catch-22 for all of us. > If people want to feed the trolls, please, for the love of all that's > holy, trim your posts. 8-) The funniest thing is that when people define what a "troll" is, they aren't just defining it for myself. Your partiality has been noted. ;-> > Sigh, this is the first technical list filter I've ever had to > implement (for email...usenet is another story). No offense but sometimes the "popular" thought or ignorance is worse than the so-called "distractive" discussion that sheds some light on it. People are building servers with CentOS. This stuff is pertinent. I do _not_ introduce it myself, but when it comes up, I _will_ offer my recommendations based on experience and background. If you see people only as "feeding" my so-called "trollish nature," then maybe that's a sign you're not looking at the real issue. I'm not innocent, and I'll _never_ claim to be. But some others are very guilty of wanting many tangents and are posting just as much as I in a thread! Think about it. ;-> -- Bryan J. Smith mailto:b.j.smith@ieee.org

16 34

RE: [CentOS] Postfix / Postini question
by Marc Powell 29 Jun '05

29 Jun '05

> -----Original Message----- > From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On > Behalf Of Barry Brimer > Sent: Wednesday, June 29, 2005 9:47 AM > To: centos(a)centos.org > Subject: [CentOS] Postfix / Postini question > > > > I have a mail server that handles several domains. One of these domains > has > decided to use Postini. For those not familiar with Postini, you set your > MX > records to use their mail servers. They filter mail, and deliver you only > the > clean virus/spam free mail. The idea is to only allow incoming mail from > their > mail servers so spammers are unable to send to your mail server directly. > This > is fairly simple to do with standard restriction classes for a dedicated > mail > server. I am not sure how to accomplish this on a shared mail server. > Ideally > I would like to instruct postfix to accept mail from anywhere for all > domains > except one domain (the one using Postini) and only allow mail destined for > that > specific domain to originate from Postini's mail servers. Any ideas would > be > greatly appreciated. I'm not a postfix guru but I don't believe that is possible with a shared server. However, it's been my experience that if your server is not listed as an MX (and it won't), MXs exist (and they will -- Postini's) then mail will not be delivered to your machine by anyone except Postini. The only two scenarios I am aware of in which mail would get delivered to your server instead of Postini's would be if a) you were listed as a fallback MX or b) no MX's were specified then the A record for your domain would be used. Have you looked through the postfix wiki, documentation, faq, mailing list, etc? That'd be the first place I'd go since they _are_ the postfix experts ;). -- Marc

3 2

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: Robert Hanson <roberth(a)abbacomm.net> > or should i be more specific with the question(s)? > the reason i ask is that i just dumped 2 gig dram in a basic > P4 Intel 3.0GHz box to play with. > regards and TIA, At more than 1GiB on Linux/x86, you must use a 4G+4G kernel (this is the default) to see more than 960MiB. This causes a signficant (10%+) performance hit. On more than 4GiB, it is worsened as more extensive paging is used. If you have 1GiB or less, you should rebuild with_out_ "HIGHMEM" support which is a 1G+3G kernel, and you'll see better performance (and memory will be limited to 960MiB). In a nutshell, you should be running Linux/x86-64 on systems with more than 1GiB for optimal performance. If you have more than 4GiB of combined system and memory mapped I/O, you should be running Opterons with I/O MMUs. Intel EM64T systems will have protections in place for both earlier generation GTL+ limitations, as well as lack of an I/O MMU. Much of the additional "tangent" surrounded the fact that there are a few so-called "32-bit" Athlons that actually have a BIOS hack and Linux kernel support so it doesn't take a performance hit. Long story short, it has to do with the fact that even so-called "32-bit" Athlons have a core and underlying interconnect platform that supports 40-bit _linear_ addressing _natively_. -- Bryan J. Smith mailto:b.j.smith@ieee.org

4 10

with CentOS 4, and certain RAM, what specific kernel then?
by Robert Hanson 29 Jun '05

29 Jun '05

greetings how about some more of that practical CentOS stuff like amount of RAM vrs specific kernel info... im sure it is in a doc somewhere yet can someone enlighten... in all cases running latest" CentOS 4.... and since we all know when we have more than one processor, it is easy to choose SMP or not... and most of us can tell if we are i386, i586, i686, AMD whatever, Opteron etc... ...yet, what "kernel type" is best at what memory sizes... i know there are standard kernel and "hugemem" kernels and SMP and what have you.... are there others ive missed? at what amount of RAM should we go hugemem? is there more than one amount depending on processor? im guessing yes. is that what a lot of the discussions are about lately? do you always use a stock kernel below that? will a hugemem kernel self destruct at RAM memory amounts lower than what amount of RAM specifically calls for "hugemem"... and again... may i ask what web document spells this all out? regards and tia - rh

2 1

Re: Offtopic Posts [was 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: Greg Knaddison <greg.knaddison(a)gmail.com> > Look - brevity is the soul of wit. It also keeps other folks on lists > from calling you a troll. The problem is that then the same people then start complaining about my "oversimplification." In fact, that's part of the problem here. I really _tried_ to make a recommendation without breaking down into the engineering non-sense. I really don't see how much "wit" I could do to satisify some people on that thread. > You pretty much get to blab as much as you want and argue with > people over tangent issues proving you are right, Dude, at this point, I'm tired of having my experience cut, sliced and diced by people who are like, "WTF does he think he is?" So you're right, I'm going to just state something _once_ and if people don't want to believe it, I'm just going to leave it. I tried several times in that thread, but yes, you are correct, I didn't stop, and I kept posting too. My apologies. > or you get to maintain "non-troll" status. Pick one, but don't > tangentially blab and get upset about being called a tangential > blabber. I don't have a problem with being called a "tangential blabber." What *I* have a problem is being singled out. Dude, re-read back in that last thread. Although I didn't stop posting, at some point, I realized it was going to have to go _deep_ before it would end. Now I've said my peace for the last time. I promise I will not repeat something more than once -- at the most, making only a 2nd post to "clarify" and if I didn't do a "good enough job" by then, I'll leave it be _regardless_. Your opinion is noted. But also note that someone else insinuated there was only *1* troll. I like holding everyone to the same standard. -- Bryan J. Smith mailto:b.j.smith@ieee.org

5 4

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: Steven Vishoot <sir_funzone(a)yahoo.com> > As Carol Brady said "what was all that about" I dont > know if anyone else feels this way, but i think this > subjuct has been beaten to death and beyond. Not sure > if i remember right, but wasnt the original post about > upgrading from 4.0 to 4.1? How did this topic become > an engineering course? sorry for being a crab...but > come on.... If you deploy servers with more than 1GB of RAM, and definitely more than 4GB of RAM, you should be aware of what limitations there are with Intel solutions. That's what this was about. If someone else wanted to make it into a discussion of board traces and other, irrelevant non-sense, then I'm sorry for getting into that with him. -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

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> 29 Jun '05

29 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 29 Jun '05

29 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

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