Re: Missing OSA/2 Interfaces
What I don't understand is, why you have to build an initrd? Isn't it sufficient to add the modules in /etc/modules? Christian Mark Post schrieb: On Fri, Aug 31, 2007 at 4:32 PM, in message [EMAIL PROTECTED], David Stuart [EMAIL PROTECTED] wrote: -snip- Where do I find initrd? A locate shows one in /boot, but it is a link to the executable, and one in /dev. But I am unable to view the contents of /dev/initrd to determine if that's the one I should be sending you. All other occurrences of initrd, as shown by locate, all appear to be source, or man pages, etc. It would be the one in /boot. It will have a name similar to /boot/initrd-2.6.5-7.286-s390x and should be a little less than 2MB in size. It's not an executable, it's a compressed image of an ext2 file system that gets loaded into real storage during the boot process. Mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- Mit freundlichen Grüßen Christian Langer Bundesamt für die Finanzen Haus I Raum 333 An der Küppe 2 53225 Bonn eMail: [EMAIL PROTECTED] Tel: 0228 99680 5199 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 signature.asc Description: OpenPGP digital signature
Re: Adding dasd with Red Hat
Mark, I'm glad that this worked for you (and those people here that you obviously help). I think that RH should maybe learn from this, but seems to me that they haven't yet. The story that I got from the FBI folks here that are working the Linux project on the mainframe tell me that the reason that we are using RHEL here is that IBM said that they supported both SLES and RHEL but recommended RHEL. I don't know at what level of IBM that recommendation came from. We have certainly seen issues here with which version of MQ Series we run under z/OS vs which version is supported under Linux with RHEL. We try to keep the same version across the board (which hasn't been possible yet). Kevin -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Sunday, September 02, 2007 11:33 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Adding dasd with Red Hat On Fri, Aug 31, 2007 at 9:36 PM, in message [EMAIL PROTECTED], John Summerfield [EMAIL PROTECTED] wrote: -snip- It might be on his job description, but probably not, he's here because he likes helping. When I first hired into the Linux Impact Team at Novell, I made sure that it would be on my job description. (At EDS, I was expected to get my real job done on top of whatever I did on my own time. Thanks to my co-workers picking up a lot of the slack, that was easier than it would have been otherwise.) My new job doesn't include this as part of it, but my manager is one of those that believes in doing what is right for the company, even if it's not part of his particular charter. (I've run into a number of those here, by the way. _Very_ refreshing.) The team that is officially responsible for fielding problems view me as more of a help than a bother, so we get along well. If I get something wrong, they know how to call me and set me straight. If they think I can help them on something, they don't hesitate to contact me. All of which is largely what I hoped for when I joined Novell. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Adding dasd with Red Hat
Kevin, it is strange, IBM should not give recommendations on one vendor over another. We all have our preferences, but I am strongly forbidden to tell customer which distribution to use. The only difference is if the support matrix shows support only for one vedor, which happens from time to time. Marian Gasparovic IBM Slovakia --- Evans, Kevin R [EMAIL PROTECTED] wrote: Mark, I'm glad that this worked for you (and those people here that you obviously help). I think that RH should maybe learn from this, but seems to me that they haven't yet. The story that I got from the FBI folks here that are working the Linux project on the mainframe tell me that the reason that we are using RHEL here is that IBM said that they supported both SLES and RHEL but recommended RHEL. I don't know at what level of IBM that recommendation came from. We have certainly seen issues here with which version of MQ Series we run under z/OS vs which version is supported under Linux with RHEL. We try to keep the same version across the board (which hasn't been possible yet). Kevin -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Sunday, September 02, 2007 11:33 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Adding dasd with Red Hat On Fri, Aug 31, 2007 at 9:36 PM, in message [EMAIL PROTECTED], John Summerfield [EMAIL PROTECTED] wrote: -snip- It might be on his job description, but probably not, he's here because he likes helping. When I first hired into the Linux Impact Team at Novell, I made sure that it would be on my job description. (At EDS, I was expected to get my real job done on top of whatever I did on my own time. Thanks to my co-workers picking up a lot of the slack, that was easier than it would have been otherwise.) My new job doesn't include this as part of it, but my manager is one of those that believes in doing what is right for the company, even if it's not part of his particular charter. (I've run into a number of those here, by the way. _Very_ refreshing.) The team that is officially responsible for fielding problems view me as more of a help than a bother, so we get along well. If I get something wrong, they know how to call me and set me straight. If they think I can help them on something, they don't hesitate to contact me. All of which is largely what I hoped for when I joined Novell. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 === Marian Gasparovic === The mere thought hadn't even begun to speculate about the merest possibility of crossing my mind. Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Performance: 31 vs 64 bit?
Assuming that I have a workload which will run effectively in 31 bit mode, does anybody know if it will run more efficiently in 31 bit mode than in 64 bit mode. That is, does 64 bit mode on System z have more overhead (either hardware or software) than 31 bit mode? Or is this another it depends question? This is not a simple either 31-bit or 64-bit decision. The latest Linux on System z distributions like RHEL5 and SLES10 are only available as 64-bit operating system. So they require a 64-bit z/VM guest to run. As already mentioned in this thread there are applications which benefit from address spaces larger than 2 GB. If you think of SAP application servers, various database servers or bigger webservers for example. If you have a smaller server running an application which has no benefit of running in 64-bit you could run the 31-bit application binary in the build-in 31-bit emulation layer in 64-bit Linux. This doesn't prevent all of the 64-bit extra cost but gives you a better performance / cost ratio. Often tests showed for such small 31-bit applications an performance advantage and a better performance to cost ratio. If you have the source of your application available you can compile the application with and without the '-m31' parameter and test the performance in your special case. Then sometimes the answer is it depends of the scenario. Mit freundlichen Gruessen/Regards Mario Held System performance engineer IBM Germany Lab, Boeblingen -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Adding dasd with Red Hat
On Mon, Sep 3, 2007 at 5:48 AM, in message [EMAIL PROTECTED], Evans, Kevin R [EMAIL PROTECTED] wrote: -snip- The story that I got from the FBI folks here that are working the Linux project on the mainframe tell me that the reason that we are using RHEL here is that IBM said that they supported both SLES and RHEL but recommended RHEL. I don't know at what level of IBM that recommendation came from. Marian is right, IBM employees are not supposed to express any preference for SLES or RHEL. I believe the prohibition is contractual in nature, i.e., SUSE (now Novell) and Red Hat wouldn't have agreed to the level of partnership they have if favoritism would be shown. (Being realistic, I know that it happens, and usually to the benefit of Novell, but it really isn't supposed to happen.) Some of IBM's other business partners are starting to sign similar agreements with both distribution providers, and their people are being told the same thing: talk about technical stuff all you like, but don't recommend one over the other so the customer is the one making the decision. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Performance: 31 vs 64 bit?
On Mon, 3 Sep 2007, Mario Held wrote: If you have the source of your application available you can compile the application with and without the '-m31' parameter and test the performance in your special case. Then sometimes the answer is it depends of the scenario. But if the distributors are only shipping 64-bit kernels, then '-m31' still does not completely answer the question about 31-bit performance. The rest of Linux will be running 64-bit, skewing the results. -- R; -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Performance: 31 vs 64 bit?
Rick Troth wrote: But if the distributors are only shipping 64-bit kernels, then '-m31' still does not completely answer the question about 31-bit performance. The rest of Linux will be running 64-bit, skewing the results. -- R; Not necessarily. Granted, the process will be running in z/Architecture mode, no matter what, but the instructions used will be 31 bit only and executing in a 31 bit addressing mode. It all depends on the cost of executing 31 bit instructions in z/Architecture (aka s390x) vs executing 31 bit instructions in ESA/390 mode (aka s390). In 31 bit addressing mode and using 31 bit (or 32 bit) instructions behave (almost) exactly the same whether you are running in z/Architecture or ESA/390 mode of operations. The timing MIGHT be different depending on the hardware implementation - but you probably WILL see a difference between that and running a process in 64 bit addressing mode that is executing 64 bit only instructions. For example, the instruction to store multiple 32 bit registers (STM) will behave the same whether you are running in z/Arch or ESA/390 mode (it will take the registers and store the 32 least significant bits of those registers (that's 1/2 of it in 64 bit and the whole thing in 32 bit) and store them in consecutive 32 bit locations) - so for that example, you could see a difference between -m64 and -m31 (even if your kernel has switched to z/Architecture at IPL). Also, it's obvious the kernel itself may use some 64 bit instructions (and thus, on the premise that 64 bit has a different cost than 31 bit) it will probably impact your user/sys ratio. But for mainly problem state (aka userland) stuff, you will probably see a difference between -m64 and -m31 (although it may only affect pointer/long movements) Again, a program making heavy use of 'long long' will probably suffer a performance impact while running in 31 bit mode. Finally, since hardware implementations are already geared towards 64 bit - I'm not even sure the performance penalty is *that* severe. However, this is a highly speculative statement ! I will concede however that measuring the overall impact might be another story. --Ivan (PS : On a side note.. this is slightly different than running 31 bit CMS on a 64 bit CP since CP switches the architecture of the dispatched context of a virtual machine thanks to SIE). -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Adding dasd with Red Hat
Mark Post wrote: On Mon, Sep 3, 2007 at 5:48 AM, in message [EMAIL PROTECTED], Evans, Kevin R [EMAIL PROTECTED] wrote: -snip- The story that I got from the FBI folks here that are working the Linux project on the mainframe tell me that the reason that we are using RHEL here is that IBM said that they supported both SLES and RHEL but recommended RHEL. I don't know at what level of IBM that recommendation came from. Marian is right, IBM employees are not supposed to express any preference for SLES or RHEL. I believe the prohibition is contractual in nature, i.e., SUSE (now Novell) and Red Hat wouldn't have agreed to the level of partnership they have if favoritism would be shown. (Being realistic, I know that it happens, and usually to the benefit of Novell, but it really isn't supposed to happen.) Some of IBM's other business partners are starting to sign similar agreements with both distribution providers, and their people are being told the same thing: talk about technical stuff all you like, but don't recommend one over the other so the customer is the one making the decision. At least as good a notion to my mind is that someone misinterpreted something someone (maybe not even someone at IBM) said. Kevin cited the advice as hearsay, and really I don't see a useful purpose to going further than that. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Performance: 31 vs 64 bit?
I wrote: But if the distributors are only shipping 64-bit kernels, then '-m31' still does not completely answer the question about 31-bit performance. The rest of Linux will be running 64-bit, skewing the results. What I was trying to say is that a 31-bit program running on a 64-bit Linux kernel will have more 64-bit concerns (and may incur more overhead) than the same 31-bit program running on a 31-bit Linux kernel. IFF THAT IS CORRECT, then there continues to be value in the 31-bit kernel. Then Ivan wrote: Not necessarily. Granted, the process will be running in z/Architecture mode, no matter what, but the instructions used will be 31 bit only and executing in a 31 bit addressing mode. It all depends on the cost of executing 31 bit instructions in z/Architecture (aka s390x) vs executing 31 bit instructions in ESA/390 mode (aka s390). There may be some difference there, true. I don't believe that was the concern of the original poster or of the intervening contributions I have read. In 31 bit addressing mode and using 31 bit (or 32 bit) instructions behave (almost) exactly the same whether you are running in z/Architecture or ESA/390 mode of operations. The timing MIGHT be different depending on the hardware implementation - but you probably WILL see a difference between that and running a process in 64 bit addressing mode that is executing 64 bit only instructions. Yes, this is probably correct. (I say, not having measured it.) For example, the instruction to store multiple 32 bit registers (STM) will behave the same whether you are running in z/Arch or ESA/390 mode (it will take the registers and store the 32 least significant bits of those registers (that's 1/2 of it in 64 bit and the whole thing in 32 bit) and store them in consecutive 32 bit locations) - so for that example, you could see a difference between -m64 and -m31 (even if your kernel has switched to z/Architecture at IPL). Clearly, yes. Also, it's obvious the kernel itself may use some 64 bit instructions (and thus, on the premise that 64 bit has a different cost than 31 bit) it will probably impact your user/sys ratio. But for mainly problem state (aka userland) stuff, you will probably see a difference between -m64 and -m31 (although it may only affect pointer/long movements) I believe we all concur that differences will be seen between -m64 and -m31 for the user space program. You hint that the 64-bit kernel induces more overhead, which agrees with my point. Again, a program making heavy use of 'long long' will probably suffer a performance impact while running in 31 bit mode. No doubt. Finally, since hardware implementations are already geared towards 64 bit - I'm not even sure the performance penalty is *that* severe. However, this is a highly speculative statement ! I cannot wait for Barton and company to measure it! I will concede however that measuring the overall impact might be another story. --Ivan -- R; -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
