Alan Cox writes about 2.4.19rc3-ac2: The SMP problems some people are having are not fixed yet. The summit changes still need some debugging work.
What is that?? -- Bjarne On Thu, 2002-07-18 at 01:03, Bjarne Thomsen wrote: > 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
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
