The assumption that the RedHat 7.3 kernel is based on 2.4.0 is all WRONG. Look what I found in ftp://sunsite.uio.no/linux/RedHat/updates/7.3/en/os/i686/ kernel-2.4.18-5.i686.rpm kernel-bigmem-2.4.18-5.i686.rpm kernel-debug-2.4.18-5.i686.rpm kernel-smp-2.4.18-5.i686.rpm
So, at least if you update, RedHat 7.3 is using a kernel based on 2.4.18, just like ML 8.2, only that a problem with highmem has been solved. Again, I attach the discussion on the kernel list about this problem with regards to the RedHat kernel. But my real question is, of course, if it has been solved for the kernel in the Mandrake cooker. -- Bjarne On Wed, 2002-07-17 at 04:00, James wrote: > On 17 Jul 2002 09:51:30 +0200 > Bjarne Thomsen <[EMAIL PROTECTED]> said with temporary authority > > > > > In the spring I encountered a problem (system freeze) with the > > LM 8.2 enterprise kernel. The problem never happened with the > > standard stock kernel of LM 8.2. That it was actually a highmem > > problem was verified by compiling the kernel with the standard > > options + the highmem option. The problem was solved by using > > the stock enterprise kernel from LM 8.1. > > > > From a discussion on the kernel list that I happened to find > > it looks as if the Red Hat 7.3 kernel had a similar problem > > for memory above 896MB. This has now been solved in the > > Red Hat 7.3 kernel for memory below 4Gb. > > But it is not clear to me if RedHat's 7.3 kernel is based > > on Rik van Riel's VM or Andrea's VM. > > >From reading the enclosed commentary (Thanks for enclosing it by the > way) it seems that RH is using the pre Linux being struck by cosmic rays > VM... Meaning the original VM from 2.4.0. or so it would seem to me. > > James > > > > > There seems to be some confusion, even on the kernel mailing > > list, so could somebody, please, explain the situation for the > > various Mandrake kernels. Has the problem been solved in > > the latest enterprise kernel in the cooker? Will it be solved > > in the new 2.4.19 kernel? > > > > To illustrate the situation, let me finish with a citation. > > > > Martin J. Bligh ([EMAIL PROTECTED]): > > >There are definitely good things in both trees for this problem area > > >at the moment. If you're interested in fixing this Alan and Andrea, > > >let's start a > > >mergefest. I'm sure I can volunteer some IBM resources to help port > > patches,>and test the hell out of it .... if you're willing to > > consider taking things, > > >I'll drawup a list of what the issues are, what patches are > > >available, and which trees they reside in (often none). > > > > So, where are the Mandrake kernels in this discussion? > > > > For easy reference I have attached an abreviated version of the > > discussion on the kernel mailing list. > > > > Dr Bjarne Thomsen > > > > Department of Physics and Astronomy > > University of Aarhus > > Denmark > > > > > > > > ---- > > Want to buy your Pack or Services from MandrakeSoft? > Go to http://www.mandrakestore.com
------------------------------------------------------------------------------ A few months ago, there was a flurry of reports from people having difficulties with memory management on large machines (ia32 over 4 GB). I've seen a lot of 2.4.x-yy kernels go by and much VM discussion, but what I'm *not* seeing is reports of either catastrophic behavior or its absence on large machines. I haven't had a chance to run my own test cases on the 2.4.18 kernel from Red Hat 7.3 yet, so I can't make any personal contribution to this discussion. -- M. Edward Borasky ------------------------------------------------------------------------------ RedHat has fixed the problem in its kernels. There are fixes out there, but Linus is not applying them. I would venture that this is because they would fix the problems *for the moment* and take away interest in revamping VM for real. It might help if Linus would actually state his intentions. So far the problem has been that the AA vm was badly documented and a big chunk of patches. Andrew Morton split them up nicely and documented each patch, so that is resolved. Regards, bert ------------------------------------------------------------------------------ 7.3 has some of what is needed but not all. To go past 16Gb you need highmem mapped page tables which I'm pretty sure did not make it in. Alan Cox ------------------------------------------------------------------------------ > 7.3 has some of what is needed but not all. Can you outline the changes in this area? I want to make sure we're not all fighting the same problems seperately ;-) I know bounce buffers is one large element of that, though I believe you still only go up to 4Gb, unless I'm mistaken? > To go past 16Gb you need highmem mapped page tables which I'm > pretty sure did not make it in. You need it earlier than that if you have many large tasks (4Gb or so). Martin J. Bligh ------------------------------------------------------------------------------ > Can you outline the changes in this area? I want to make sure we're > not all fighting the same problems seperately ;-) I know bounce > buffers is one large element of that, though I believe you still > only go up to 4Gb, unless I'm mistaken? Bounce buffer handling > You need it earlier than that if you have many large tasks (4Gb or so). That I can believe Alan Cox ------------------------------------------------------------------------------ > Can you outline the changes in this area? I want to make sure we're > not all fighting the same problems seperately ;-) I know bounce > buffers is one large element of that, though I believe you still > only go up to 4Gb, unless I'm mistaken? Yes, it only goes up to 4Gb. It's because of the error handling code in the SCSI mid-layer and above, it fails to properly handle the >4gb sg entries on error conditions. I'm working on that now and should have it fixed soon. Doug Ledford ------------------------------------------------------------------------------ > ... Linus is not applying them Shouldn't that be "Marcelo is not applying them"? Linus has devolved all responsibility for 2.4 now, and is concentrating on the 2.5 series and all its radical changes. Marcelo objected to Andrea's mega-patch, but if I recall, he hinted that me might start merging the split-up patches for 2.4.20 - in the meantime, you can always apply the latest -aa patch yourself to a 2.4.19-pre kernel. Otherwise, the Red Hat patched kernel (which I believe still doesn't use Andrea's VM at all) ought to work well, with all their spiffy regression testing etc.... Cheers Alastair Stevens ------------------------------------------------------------------------------ > 2.4.19-pre kernel. Otherwise, the Red Hat patched kernel (which I > believe still doesn't use Andrea's VM at all) ought to work well, with > all their spiffy regression testing etc.... The Red Hat 7.3 kernel uses Rik van Riel's rmap and Andre Hedricks IDE updates. It did indeed pass our stress testing and seems to perform very well under memory contention and high shared page counts - the classic desktop/developer set up. Alan ------------------------------------------------------------------------------ The catastrophic failures are still happening, in fact, the last lse-tech conference call a week or two ago was dedicated at least in part to them. The number of different ways in which these failures occur is large, so it's taking a while for the iterations of whack-a-mole game to converge to kernel stability. Andrea has probably been doing the most visible stuff on this front with the recent bh/inode exhaustion patches, with due credit to akpm as well for the unconditional bh stripping patch. Cheers, Bill (William Lee Irwin III) ------------------------------------------------------------------------------ > I wouldn't bother using RedHat's kernel for this at the moment, > Andrea's tree is where the development work for this area has all > been happening recently. He's working on integrating O(1) sched > right now, which will get rid of the biggest issue I have with -aa > at the moment (the issue being that I'm too busy to merge it ;-)). Oh, of course, I left of the bounce buffer issue, which RedHat *have* fixed in their tree, I believe. Not sure what the status of this work is for -aa at the moment. Martin J. Bligh ------------------------------------------------------------------------------ > I wouldn't bother using RedHat's kernel for this at the moment, > Andrea's tree is where the development work for this area has all > been happening recently. He's working on integrating O(1) sched > right now, which will get rid of the biggest issue I have with -aa Still ? Its been in the Red Hat 7.3 tree since we released it. Its also in the -ac tree all nicely merged. I guess your definition of happening is my definition of "happened" 8) Alan Cox ------------------------------------------------------------------------------ >Still ? Its been in the Red Hat 7.3 tree since we released it. Its also >in the -ac tree all nicely merged. I guess your definition of happening >is my definition of "happened" 8) > Huh? RH 7.3 kernel has the O(1) scheduler merged? If the RH kernel is anything like the 2.4.19-pre8-ac5 I'm currently running, that is sweet indeed. Joe ------------------------------------------------------------------------------ > Huh? RH 7.3 kernel has the O(1) scheduler merged? > > If the RH kernel is anything like the 2.4.19-pre8-ac5 > I'm currently running, that is sweet indeed. rpm -q --changelog |grep "O(1)" Alan Cox ------------------------------------------------------------------------------ > >rpm -q --changelog |grep "O(1)" > > > Yes, I was being lazy - but now that finals are done with for now, I'll grab that kernel source rpm and have a proper look at it. Thanks, Joe ------------------------------------------------------------------------------ > Still ? Its been in the Red Hat 7.3 tree since we released it. Its also > in the -ac tree all nicely merged. I guess your definition of happening > is my definition of "happened" 8) There are definitely good things in both trees for this problem area at the moment. If you're interested in fixing this Alan and Andrea, let's start a mergefest. I'm sure I can volunteer some IBM resources to help port patches, and test the hell out of it .... if you're willing to consider taking things, I'll drawup a list of what the issues are, what patches are available, and which trees they reside in (often none ;-( ) If my spies are correct, 7.3AS kernel is still based off the old 2.4.9 VM, with no rmap at present ... correct? I presume 7.3 is 2.4.18 or so VM with rmap? Martin J. Bligh ([EMAIL PROTECTED]) ------------------------------------------------------------------------------ > If my spies are correct, 7.3AS kernel is still based off the old > 2.4.9 VM, with no rmap at present ... correct? I presume 7.3 is > 2.4.18 or so VM with rmap? <Red Hat Marketing>There is no such product as 7.3AS</Red Hat Marketing> ;) The AS 2.1 kernel is 2.4.9 based for enterprise stability with the pre Linus being hit by cosmic rays VM fixed and tuned for enterprise workloads. 7.3 is the rmap VM Alan ------------------------------------------------------------------------------
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
